--- title: "Validation Services" description: "Configure email, phone, and address validation services to improve data quality and reduce fraud. (Identity validation is an unreleased beta placeholder — see the Identity Validation section.)" --- > Documentation Index > Fetch the complete documentation index at: https://docs.sparkcrm.io/llms.txt > Use this file to discover all available pages before exploring further. # Validation Services Validation services verify customer data during order processing, improving data quality and reducing fraud. **Navigation**: Settings > Order Enrichment & QA ![screenshot of email validation settings page](/assets/validation/spark_va_1.png) --- ## Overview Spark CRM integrates with third-party validation providers to verify: - **Email addresses** - Deliverable and not disposable - **Phone numbers** - Valid and properly formatted - **Shipping addresses** - Deliverable and standardized - **Identity** - Not yet available. Identity validation is a beta placeholder; contact support to register interest. Email, phone, and address validation are each optional and billed per verification. --- ## Email Validation **Navigation**: Settings > Email Validation Verify that customer email addresses are real and deliverable. ![screenshot of email validation settings page](/assets/validation/spark_va_2.png) ### Benefits - Reduce email bounces - Detect disposable/temporary emails - Identify risky email patterns - Improve deliverability ### Configuration Email validation is switched on under Billing > Manage Services. Until it is enabled this screen is read-only — the rules list is blurred behind a padlock and the Add Rule / Reset to Defaults buttons are hidden. Email validation always uses ZeroBounce; the provider is not selectable per team. Provider credentials are managed by Spark CRM at the platform level; merchants do not supply a ZeroBounce API key. Timing is not configurable either — lead-capture orders validate asynchronously on the `validations` queue, while full-order and payment API calls validate synchronously before the charge. The screen manages a prioritised list of validation rules. A rule pairs a **Condition** with an **Action**: | Field | Description | |-------|-------------| | **Condition** | What the provider result must show. Email offers 9 conditions: Syntax/Format Error, Disposable Email, Spam Trap, Abuse/Complaint Email, Do Not Mail, Invalid Domain, Contains Typo, Role-based Email, Government Email (.gov, .mil). | | **Action** | **Send to QA**, **Decline Order**, **Flag Only (No Action)**, plus **Auto Correct** — offered only when the condition is **Contains Typo**. Changing the condition away from Contains Typo resets an Auto Correct selection back to Send to QA. **Decline Order** is stored on the rule but is not currently enforced by the validation engine — only **Send to QA** (and **Auto Correct** on email typos) changes what happens to the order. To make a flagged order decline, set **QA Settings > QA Action** to **Decline Order**. | | **Priority** | Lower numbers are processed first. Saving a rule onto an existing priority shifts the colliding rules down automatically; deleting a rule closes the gap. | | **Active** | Switch a rule on or off without deleting it (also togglable from the Status column in the table). | | **Description** | Optional, max 255 characters. Used as the QA reason when the rule fires. | Controls: **Add Rule** opens the flyout; the row menu offers **Edit** and **Delete** (with a confirmation modal); the up/down arrows in the Priority column reorder rules; **Reset to Defaults** deletes every existing email rule and reseeds the 5 email defaults — this cannot be undone. Rules are paginated 10 per page. ### Validation Results Results are stored on the customer record: | Field | Description | |-------|-------------| | `is_email_valid` | Whether email passed validation | | `email_validated_at` | When validation occurred | | `email_validation_meta` | Detailed validation response | ### Use Cases - Block orders with invalid emails (the rule sends them to QA; blocking requires **QA Settings > QA Action** set to **Decline Order**) - Flag suspicious email patterns for QA - Clean customer email lists --- ## Phone Validation **Navigation**: Settings > Phone Validation Verify that customer phone numbers are valid and properly formatted. ![screenshot of phone validation settings page](/assets/validation/spark_va_3.png) ### Benefits - Verify phone numbers are real - Standardize phone number formats - Identify carrier and line type - Improve contact rates ### Configuration Phone validation is switched on under Billing > Manage Services; until it is enabled this screen is read-only. Phone validation always uses Twilio Lookup; the provider is not selectable. Twilio credentials are held by Spark CRM at the platform level; merchants do not enter them. The screen manages a prioritised list of validation rules. A rule pairs a **Condition** with an **Action**: | Field | Description | |-------|-------------| | **Condition** | What the provider result must show. Phone offers 6 conditions: Invalid Phone Number, Non-Fixed VOIP, Country Mismatch with Shipping, Landline Number, Prepaid Phone, Disconnected/Inactive. | | **Action** | **Send to QA**, **Decline Order**, or **Flag Only (No Action)**. Auto Correct is offered only on the email **Contains Typo** condition. **Decline Order** is stored on the rule but is not currently enforced by the validation engine — only **Send to QA** changes what happens to the order. To make a flagged order decline, set **QA Settings > QA Action** to **Decline Order**. | | **Priority** | Lower numbers are processed first. Saving a rule onto an existing priority shifts the colliding rules down automatically; deleting a rule closes the gap. | | **Active** | Switch a rule on or off without deleting it (also togglable from the Status column in the table). | | **Description** | Optional, max 255 characters. Used as the QA reason when the rule fires. | Controls: **Add Rule** opens the flyout; the row menu offers **Edit** and **Delete** (with a confirmation modal); the up/down arrows in the Priority column reorder rules; **Reset to Defaults** deletes every existing phone rule and reseeds the 3 phone defaults — this cannot be undone. Rules are paginated 10 per page. ### Validation Results Results are stored on the customer record: | Field | Description | |-------|-------------| | `is_phone_valid` | Whether phone passed validation | | `phone_validated_at` | When validation occurred | | `phone_validation_meta` | Carrier, line type, etc. | ### Use Cases - Block orders with invalid phones (the rule sends them to QA; blocking requires **QA Settings > QA Action** set to **Decline Order**) - Format phones for SMS campaigns - Identify VOIP vs mobile numbers --- ## Address Validation **Navigation**: Settings > Address Validation Verify that shipping addresses are real and deliverable. ![screenshot of address validation settings page](/assets/validation/spark_va_4.png) ### Benefits - Reduce failed deliveries - Standardize address formatting - Identify residential vs commercial - Lower shipping costs ### Configuration Address verification is switched on under Billing > Manage Services, where it is labelled **Address Verification**; until it is enabled this screen is read-only. Address validation always uses Smarty (SmartyStreets); the provider is not selectable. Smarty credentials are held by Spark CRM at the platform level. The screen manages a prioritised list of validation rules. A rule pairs a **Condition** with an **Action**: | Field | Description | |-------|-------------| | **Condition** | What the provider result must show. Address offers 7 conditions: Invalid Address, Missing Apt/Suite Number, Reship/Freight Forwarder, PO Box Address, Undeliverable Address, Commercial Address, Unknown/Unverified Address. | | **Action** | **Send to QA**, **Decline Order**, or **Flag Only (No Action)**. Auto Correct is offered only on the email **Contains Typo** condition. **Decline Order** is stored on the rule but is not currently enforced by the validation engine — only **Send to QA** changes what happens to the order. To make a flagged order decline, set **QA Settings > QA Action** to **Decline Order**. Address evaluation also stops at the first matching rule, so a matching rule whose action is not **Send to QA** suppresses every lower-priority address rule. | | **Priority** | Lower numbers are processed first. Saving a rule onto an existing priority shifts the colliding rules down automatically; deleting a rule closes the gap. | | **Active** | Switch a rule on or off without deleting it (also togglable from the Status column in the table). | | **Description** | Optional, max 255 characters. Used as the QA reason when the rule fires. | Controls: **Add Rule** opens the flyout; the row menu offers **Edit** and **Delete** (with a confirmation modal); the up/down arrows in the Priority column reorder rules; **Reset to Defaults** deletes every existing address rule and reseeds the 4 address defaults — this cannot be undone. Rules are paginated 10 per page. ### Validation Results Address validation can: - Confirm address exists - Suggest corrections - Standardize formatting - Add missing components (ZIP+4) | Field | Description | |-------|-------------| | `is_deliverable` | Whether address can receive mail | | `verification_data` | Full provider response, including `standardized_address` (with ZIP+4 as `plus4`), `address_type`, `delivery_point` and `is_vacant` | When the address validates successfully the standardized street, city, state and postal code are also written back over the address record itself. ### Use Cases - Block undeliverable addresses (the rule sends them to QA; blocking requires **QA Settings > QA Action** set to **Decline Order**) - Auto-correct address typos - Flag PO boxes if not supported --- ## Identity Validation **Navigation**: Settings > Identity Validation Identity validation is not yet released. The tab shows a **BETA** card headed **Feature Coming Soon**: "Identity validation is currently in beta development. To activate this feature on your account, please contact our support team." The only control is a **Contact Support** button. There is nothing to configure, no provider, and no billing unit for identity validation today. ![screenshot of identity validation settings page](/assets/validation/spark_va_5.png) --- ## Billing Validation services are billed per verification: | Service | Billing Unit | |---------|--------------| | Email Validation | Per email verified | | Phone Validation | Per phone verified | | Address Validation | Per address verified | View current rates on the **Billing** page (account menu > Billing) under **Manage Services**, where each service shows its per-verification fee. Opening the Billing page requires permission to manage billing — the team owner, a super admin, or a member with the `manage:billing` team permission. Demo teams are blocked from the page entirely. --- ## When Validation Runs Validation timing is decided by the API endpoint that created the order: ### Order Time (Synchronous) - Runs before the charge on full-order and payment API calls - A matching rule flags the order for QA; it does not block on its own - Whether a flagged order is blocked depends on **QA Settings > QA Action** (**Decline Order** blocks; the default, **Complete Charge**, charges the card and flags the order for review) ### Asynchronous (lead capture) - Orders created through the lead/prospect endpoint queue validation on the `validations` queue (5-second delay) instead of validating inline - A matching rule flags the order for QA once the job runs - There is no automatic post-completion validation pass; you can, however, re-run validation manually from an order or customer record Trigger timing is not configurable — it is determined by the API endpoint that creates the order. What you can control per type is whether it runs at all: switch each service on or off under Billing > Manage Services, or bypass a type on an individual campaign. --- ## Integration with QA Validation results can trigger QA review: 1. **Validation fails**: Order flagged for review 2. **Risky indicators**: Email is disposable, address is commercial, etc. 3. **QA team reviews**: Approve or reject order Configure QA rules in [QA Settings](/settings/qa-settings). --- ## Best Practices ### Enable Gradually 1. Start with email validation (highest impact) 2. Add address validation for physical products 3. Add phone validation if using SMS ### Balance Friction - Full-order and payment API calls validate before the charge, so they add latency to checkout - Lead-capture orders validate on the queue, so they add none - To cut friction on a specific funnel, bypass a validation type on that campaign rather than looking for a timing setting ### Monitor Costs - Track validation volume in billing - Turn a service off under Billing > Manage Services, or bypass it on a campaign, if costs run high - Only validate when valuable ### Handle Failures - Decide: block order or flag for QA? - Provider outages are handled platform-side — contact support if validations stop returning results - Log all validation results --- ## Troubleshooting ### Validation Not Running **Check:** - The service is switched on under Billing > Manage Services - Billing is current - The campaign does not set a bypass flag (`bypass_email_validation` / `bypass_phone_validation` / `bypass_address_validation`) - At least one active rule exists for that validation type Provider credential and outage problems are platform-side — contact support rather than looking for a key to fix. ### High Failure Rate **Check:** - Validation rules aren't too strict - Provider is working correctly - Traffic quality issues ### Slow Checkout **Check:** - Bypass a validation type on the campaign (`bypass_email_validation` / `bypass_phone_validation` / `bypass_address_validation`) - Or turn a type off entirely under Billing > Manage Services - Validation calls already run concurrently with a 10-second timeout and up to 3 attempts (retried only on rate limits, provider 5xx errors, or connection failures), so a slow checkout usually means a provider is degraded — contact support --- ## Related Topics - [QA Settings](/settings/qa-settings) - Quality assurance workflow - [Blacklists](/settings/blacklists) - Block specific customers Source: https://docs.sparkcrm.io/settings/validation/index.mdx