Verify emails and phone numbers in Salesforce with Spaw

Salesforce orgs collect addresses through web-to-lead forms, list imports and integrations, and a bad address on a lead costs a rep's time before it bounces. Spaw does not publish an AppExchange package. The recommended path is a Zap or a Make scenario that triggers on a new lead or contact, verifies the address, and writes the verdict into custom fields that your reports, list views and flows can use. The record's phone number takes a second flow of the same kind.

Prepare the org

1. Add three custom fields to Lead, and the same three to Contact if you verify both: a picklist or text field for the verdict, a text field for the reason, and a number field for the risk score. Names such as Email_Verdict__c, Email_Verdict_Reason__c and Email_Risk_Score__c read well in reports.
2. Create a secret API key on the API keys page of your Spaw dashboard.

Verify new records as they are created

1. In Zapier or Make, start with the Salesforce trigger for a new record and choose the Lead object (or Contact).
2. Add the verification step: a Webhooks by Zapier POST or a Make HTTP request to https://spaw.co/api/v1/email with the header Authorization: Bearer sk_live_… and this body, mapping the record's email:

{
  "email": "[email protected]"
}

The Zapier page and the Make page walk through the exact settings. When the Spaw apps for both platforms are listed, the step becomes a Verify Email action with a saved connection; the fields do not change.

3. Add a filter so records without an email are skipped.
4. Add the Salesforce action that updates a record, pick the same object, match on the record id from the trigger, and map data.deliverable, data.reason and data.risk_score into the custom fields.
5. Test by creating a lead with the address [email protected], one of six free test addresses that answer a fixed result and never appear in your history.

Teams that prefer to stay inside Salesforce can call the same endpoint from Apex with a Named Credential holding the bearer token; the OpenAPI document describes every request and response for that work. This page keeps to the no-code path.

Clean existing leads and contacts

Export the addresses with their record ids, run the file through a bulk verification on the Spaw dashboard or with the bulk endpoint, and load the result CSV back with a data loader, matching on the id. The result keeps your original columns and adds the verdict, reason, risk score and suggestion columns, so the mapping is one to one. Undeliverable rows also land on your Spaw suppression list, which later batch and bulk runs answer for free.

What to do with the verdict

Build list views and assignment rules on the verdict field. deliverable leads route to reps as usual. risky leads deserve a look at the reason before a sequence: catch_all means the domain accepts every address and the mailbox is unconfirmed, role means a shared inbox, disposable means a throwaway domain. undeliverable leads should be flagged rather than deleted, because a filled data.did_you_mean value, for example [email protected] for [email protected], is often a lead worth one correction. A validation rule or flow can block a lead from converting while the verdict is undeliverable.

Phone numbers

A second Zap or scenario on the same trigger validates the lead's or contact's phone number.

1. Add four more custom fields to the same objects: text fields for the E.164 number, the line type and the blocking reason, and a checkbox for whether sending is allowed. Names such as Phone_E164__c, Phone_Line_Type__c, Phone_Blocked_By__c and Phone_OK_To_Send__c sit next to the email fields in reports.
2. Start that Zap or scenario with the same new-record trigger and object, and a filter that continues only when the record's Phone (or Mobile) field is filled (an empty phone is refused with a 422). In it, add a Webhooks by Zapier POST or a Make HTTP request to https://spaw.co/api/v1/phone with the same header and this body, mapping that field:

{
  "phone": "(202) 555-0100",
  "country": "US"
}

3. Give that flow an update-record action of its own on the same object, matched on the record id from the trigger, that maps data.e164, data.line_type, data.blocked_by and data.ok_to_send into the four fields. Kept separate, a record without a phone number still gets its email verdict, and a record without an email still gets its phone number checked.
4. Test by creating a lead with the phone number +1 202 555 0100, then +1 202 555 0103: two documented test numbers that cost nothing, the first answering a valid mobile with ok_to_send true, the second ok_to_send false with blocked_by disposable, under the default SMS policy.

country is optional and must be an ISO 3166-1 alpha-2 code. A number stored with its + and calling code needs none, and a national number sent without one answers valid: false with the reason missing_country, free. Do not map the address's Country field as it stands when it holds names: "United States", or UK (the code is GB), is refused with a 422. Map a field that holds the two-letter code, add a formula field that converts your org's names, or type the one country your records come from into the step. Send the number and its country only, nothing else about the person. Once the Spaw apps are listed, the step becomes the Validate Phone Number action in Zapier and Validate a Phone Number in Make.

Phone_E164__c is the form to dedupe and match records by. It is also kept for an invalid number in a block nobody holds, so read it together with the checkbox, which is false for every invalid number. Before a flow step that texts the record, check the checkbox: ok_to_send is your account's SMS policy applied to the answer, set once on the account so every Zap, batch and bulk run applies the same rules, and blocked_by names the rule that decided a false. It is a fraud and deliverability decision, not consent and not a do-not-call scrub. line_type comes from the numbering plan or, for a North American number, from the holder of its block in the regulator's table; it describes how the range was allocated, never the network that serves the number after a port, and an ordinary US number answers fixed_line_or_mobile unless its block holder settles the type (why). Leave the complaint counts (complaints_90d, complaints_last_at) off leads and contacts: they count the complaints consumers sent the FTC naming a number as the caller, which is not the Do Not Call Registry and says nothing about whether you may call or text the number, and the reports are unverified, with caller ID often spoofed. Every field is on the phone endpoint page.

Cost

Each new record that answers deliverable or risky spends 1 credit; unverified answers and repeats within seven days are free, as are the test addresses, and undeliverable answers are free within a fair-use allowance. A phone lookup costs 1 credit when the number is valid; invalid numbers, unassigned blocks, the test numbers and repeats of the same number within seven days are free. Zapier and Make bill their own tasks. A bulk run bills per row as it is processed and verifies duplicates once.