How to validate emails in Zapier without a native app

You want to validate emails in Zapier — catch the typos, the throwaway addresses, and the asdf@asdf.com submissions before they land in your CRM and rot your deliverability. Good instinct. Before you reach for an API, though, know what you already have: Zapier's built-in Formatter can lowercase and trim an address, and a plain filter can reject anything without an @. For a surprising number of Zaps, that's genuinely enough. The trouble starts when you need to know whether a domain can actually receive mail, or whether someone signed up with a ten-minute inbox. That's the layer past Formatter — and that's where a call out to a validation API earns its keep.

There is no native Boundstone app — and that's fine#

Let's state it plainly: there is no native or official Boundstone app in the Zapier marketplace. A native integration is planned, but today you connect the same way you'd connect any REST API — through Webhooks by Zapier, which is a premium Zapier action. If your plan includes premium apps, you already have it. One POST step does the whole job. You don't need code, and you don't need to wait for a marketplace listing.

If you only want to eyeball a few addresses first, the free keyless email validator runs the exact same checks in your browser, no account required. When you're ready to wire it into a Zap, read on.

Add the "Webhooks by Zapier" POST action#

In your Zap, add an action step and pick Webhooks by Zapier → POST. Configure it like this:

• URL: https://api.boundstone.io/v1/verify/email
• Payload Type: JSON
• Data: one field, email, mapped to the email field from your trigger (a form entry, a new row, a signup event — whatever fired the Zap).
• Headers: one header, Authorization, with the value Bearer bs_live_YOUR_KEY.

The Data section, expressed as JSON, is exactly this:

{
  "email": "{{trigger__email}}"
}

{{trigger__email}} is Zapier's mapped field — you click to insert it from the previous step, you don't type it.

Test the step. A valid address comes back like this:

{
  "valid_syntax": true,
  "domain": "example.com",
  "mx_found": true,
  "disposable": false,
  "role_account": false,
  "free_provider": false,
  "checks": {
    "performed": ["syntax", "mx", "disposable_list", "role_list"],
    "not_performed": ["smtp_mailbox", "catch_all"]
  }
}

Every field you can filter on is right there: valid_syntax, mx_found, disposable, role_account, free_provider.

Read the checks before you trust the "valid"#

Here's the part most validation tutorials skip. That checks object is the whole point. checks.performed for a valid address is ["syntax", "mx", "disposable_list", "role_list"] — we confirmed the syntax parses, the domain publishes MX records, and the address isn't on a disposable or role list. checks.not_performed is ["smtp_mailbox", "catch_all"] — we did not open an SMTP conversation with the mailbox, and we did not test whether the domain accepts every address (a catch-all). Those two are hard to do accurately and quietly, so we don't pretend to.

What that means for your Zap: a passing result tells you the address is well-formed and the domain can receive mail. It does not promise a human is reading that specific inbox. Filter on what was actually checked, and you'll never be surprised by a field that was quietly guessed.

Add a Filter step on disposable#

Now gate the rest of your Zap. Add a Filter by Zapier step immediately after the webhook and set two conditions, both of which must be true:

• valid_syntax — (Boolean) is true
• disposable — (Boolean) is false

Only addresses that clear both continue down the Zap; everything else stops there, so the throwaway mailinator.com and guerrillamail.com signups never reach your CRM or your welcome sequence. If you'd rather branch than block — say, route disposable signups to a review sheet instead of dropping them — use Paths by Zapier with the same conditions.

Want the reasoning behind blocking disposables at the door instead of cleaning up later? That's its own topic: why you block disposable email at signup.

Keep the key in the step, not in a shared sheet#

Your bs_live_ key is a server-side secret. It lives in the Webhooks header of the Zap step, and that's the right place for it — Zapier stores it with the Zap, not in any spreadsheet, form, or record the Zap touches. Don't paste it into a Google Sheet cell, into a Formatter step's visible text, or anywhere a collaborator browsing your data would see it. If you export or share the sheet the Zap writes to, the key isn't in it. And if the key is ever exposed, rotate it from your dashboard — the old one dies immediately.

The short version#

• No native app yet (it's planned). You validate emails in Zapier with a Webhooks by Zapier → POST step — a premium Zapier action.
• POST to https://api.boundstone.io/v1/verify/email, Payload Type JSON, Data {"email": "{{mapped field}}"}, header Authorization: Bearer bs_live_....
• Add a Filter step: continue only when valid_syntax is true and disposable is false. Use Paths if you'd rather branch.
• The response tells you what it checked (syntax, mx, disposable_list, role_list) and what it didn't (smtp_mailbox, catch_all). Trust the "valid" accordingly.
• Keep the bs_live_ key in the webhook header, never in a shared sheet.

The free tier is 250 checks a month, no card, and the credits don't expire — enough to validate a small Zap's traffic indefinitely. The full field reference and rate limits live in the docs.