Verify emails in Zapier with Spaw

Zapier is where most teams first wire a verification step between a form, a CRM and a mailing list. Spaw fits in two ways: today, any Zap can call the REST API through Zapier's own Webhooks app; soon, a Spaw app built by us will offer the same lookups as ordinary actions with a saved connection. This page covers both, in that order.

What works today: Webhooks by Zapier

Webhooks by Zapier is a premium app, so it needs a paid Zapier plan. Everything else is a plain HTTPS call.

1. Create a secret API key on the API keys page of your Spaw dashboard. It starts with sk_live_. Publishable pk_ keys are locked to browser origins and will not work from Zapier.
2. Open the Zap that receives the address, for example a new form entry or a new CRM contact, and add an action step using Webhooks by Zapier.
3. Choose the POST event. Set the URL to https://spaw.co/api/v1/email and the payload type to JSON.
4. Under the data fields, add one key named email and map it to the address from the trigger step.
5. Under headers, add Authorization with the value Bearer sk_live_… using your key.
6. Test the step. A good first test address is [email protected], which answers a canonical result, costs nothing and never appears in your history.

The request Zapier sends looks like this:

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

The answer is the full verification result. Zapier flattens nested JSON, so the verdict shows up in later steps as the data field deliverable (the raw key is data__deliverable), the reason as reason, the risk score as risk_score, and the typo suggestion as did_you_mean. All 27 fields of the single-address response are available for mapping.

For a Zap that handles a list rather than one address at a time, point the same step at https://spaw.co/api/v1/email/batch and send { "emails": [...] } with up to 50 addresses. The batch endpoint answers in input order and counts as one request against the rate limit.

The Spaw app for Zapier

A Spaw app for Zapier is built and is going through Zapier's publishing process; it is not in the Zapier app directory yet. When it is, this page will carry the link. It replaces the manual webhook step with these pieces:

• A connection that takes your secret API key once and labels itself with your account email.
• Actions: Verify Email, Verify Emails (up to 50 addresses, one per line), Check Domain, and Add to Suppression List.
• A search step, Find Email Verdict, so a lookup can sit in a path or a filter the way Zapier expects lookups to.
• Errors that name the API code, so an empty balance reads INSUFFICIENT_CREDITS in the Zap history rather than a generic failure, and rate limits are retried automatically.

Nothing about the data changes between the two paths. The app calls the same endpoints with the same fields, so a Zap built on Webhooks by Zapier today can be moved over field by field later.

What to do with the verdict

Add a Filter or a Paths step right after the verification step and branch on deliverable. A deliverable answer continues to the CRM or mailing list as usual. A risky answer deserves a look at reason: catch_all and role addresses are often fine to keep with a lower priority, while disposable rarely is. An undeliverable answer should stop the Zap or route the record to a review list, and when did_you_mean is filled, for example [email protected] for [email protected], you can write the correction back instead of discarding the lead. Teams that prefer one number to branch on use risk_score, which is a published sum of weights rather than a black box.

Cost

Each Zap run that verifies an address spends 1 credit when the answer is deliverable or risky. Undeliverable answers, invalid input, and repeats of the same address within seven days cost nothing. The Zapier task itself counts against your Zapier plan as any action does. A key may make 5 requests per second; a Zap that fires faster than that receives RATE_LIMITED with a Retry-After header, and Zapier's replay handles the rest.