Verify emails and phone numbers from Typeform with Spaw

Typeform checks that an email answer looks like an address, and nothing more. A response with [email protected] passes and lands in your CRM as a lead nobody can reach. Because Typeform hosts the form and does not run your scripts, the Spaw form helper cannot watch the field the way it does on your own pages; verification happens right after submission instead, in the Zap or Make scenario that already carries the response onward. A phone-number question gets the same treatment in a second step, covered below.

Verify each response

1. Create a secret API key on the API keys page of your Spaw dashboard.
2. In Zapier or Make, start with the Typeform trigger for a new response and pick the form.
3. 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 email question's answer:

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

The Zapier page and the Make page show the step in detail. When the Spaw apps for those platforms are listed, it becomes a Verify Email action with a saved connection.

4. Add a filter or router on data.deliverable from the response.
5. Send deliverable and risky responses on to their destination as before, for example a CRM contact or a sheet row, and map data.deliverable, data.reason and data.did_you_mean into extra fields there.
6. Route undeliverable responses to a review sheet or a notification instead of the CRM.
7. Test by submitting the form with [email protected], a free test address that answers a fixed result and is never logged.

The response also contains every field of the single-address result, including whether the domain is a free provider, whether the address is a role inbox, and the risk score, so the destination can hold as much or as little as you need.

Forms on your own site

If the form is a page you control rather than a hosted Typeform, the form helper checks the address while the visitor is still typing and offers the correction before they submit, which is the better moment, and it checks a phone input marked data-spaw-phone as well, showing the international format of a valid number or the reason one is not valid. The two approaches combine well: the helper on your own pages, the Zap for hosted forms.

What to do with the verdict

The most valuable field here is data.did_you_mean. A form typo is usually a real person who wants to hear from you, so when the suggestion is filled, for example [email protected] for [email protected], create the record with the corrected address and note the original. For risky responses, look at data.reason: disposable addresses were entered to get past the form and can be dropped, role inboxes and catch_all domains are usually worth keeping with lower priority. For a single threshold, data.risk_score is 0 to 100 with published weights, as the regex guide explains.

Phone numbers

A phone-number question gets its own step in the same Zap or scenario, placed before any filter on the email verdict so an undeliverable email does not stop it: 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 the phone answer:

{
  "phone": "+1 202 555 0100"
}

A number that arrives with its + and calling code needs nothing else. If the form collects numbers from one country without the code, add country with that country's ISO 3166-1 alpha-2 code, such as US. If a separate question asks for the country, map it only when its answers are two-letter codes: a country name, or UK (the code is GB), is refused with a 422. A national number sent without a country answers valid: false with the reason missing_country, free. phone itself is required, so an unanswered question is refused with a 422 and stops the run; if the question is optional, put the step on a Paths branch in Zapier or a router route in Make that runs only when the answer is filled. Once the Spaw apps are listed, the step becomes the Validate Phone Number action in Zapier and Validate a Phone Number in Make.

Send data.e164 on to the destination as the number to store: it is the one E.164 form of the number however the respondent typed it, so records dedupe on it. Before any step that texts the respondent, filter or route on data.ok_to_send. It 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 when it is false data.blocked_by names the rule that decided it: invalid, opted_out (by default) for a number your suppression list holds as opted out, country, line_type, a signal such as disposable for a number published by an SMS-receiving website, where anyone can read a code sent to it, or risk_score. It is a fraud and deliverability decision, not consent and not a do-not-call scrub. For an invalid answer sent with a country, data.did_you_mean may hold the one valid reading of the digits, for example a number typed without its +; unlike the email suggestion, keep it as a note for a person to confirm rather than writing it over the answer. Every field is on the phone endpoint page.

Test with +1 202 555 0100 and +1 202 555 0103, two documented test numbers that cost nothing: the first answers a valid mobile with ok_to_send true, the second ok_to_send false with blocked_by disposable, under the default SMS policy.

Cost

Each response that answers deliverable or risky spends 1 credit; unverified answers, the test addresses, and repeats of the same address within seven days are free, 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 form with a few hundred responses a month stays well inside a small credit pack.