Twelve moments in an ordinary SaaS product are worth a verification call: the signup form, the free trial gate, teammate invites, checkout and receipts, password reset requests, gated downloads, CRM records and bulk imports, contacts created by automations, re-verification before a lifecycle send, support tickets that arrive by email, marketplace signups on both sides, and addresses that partners push through your own API.
The email verification API use cases below share a shape. Something happens, your code hands one address to a web service (that is all an API is here: software talking to software), a verdict comes back in well under a second, and you decide what the person sees. Each one names the moment it runs, the verdict worth acting on, the user-facing behavior, and the mistake teams usually make.
If you are weighing this against a bot check, that is a different question and we took it apart in email verification API vs CAPTCHA.
What a verdict actually contains
“Valid or not” is a poor summary of what comes back, and the difference matters for almost every decision below.
Reoon’s API documentation describes two modes. Quick mode returns email, status, username, domain, is_valid_syntax, is_disposable, is_role_account, mx_accepts_mail, is_spamtrap, is_free_email, mx_records and verification_mode. The docs put it within 0.5 seconds and say plainly that it does not check individual inbox status. Its status comes back as valid, invalid, disposable or spamtrap.
Power mode goes after the mailbox itself and adds overall_score, is_safe_to_send, can_connect_smtp, has_inbox_full, is_catch_all, is_deliverable and is_disabled. Its status can be safe, invalid, disabled, disposable, inbox_full, catch_all, role_account, spamtrap or unknown. The documentation is honest about the cost: power mode can take from a few seconds to more than a minute, which puts it in background jobs rather than in front of a waiting user.
Two values need a plain definition. A catch-all domain accepts mail for every address at it, real or not, so no outside check can confirm one specific mailbox there. unknown means the mail server refused to give a usable answer. Neither is a rejection. Treating them as one is the quickest way to turn away real customers.
Twelve email verification API use cases, moment by moment
1. The signup form
Runs on submit, before you write the account row. Act on invalid, and on mx_accepts_mail coming back false, which means the domain has no mail server at all. What the user sees matters more than the block: [email protected] deserves an inline “Did you mean gmail.com?” with a one-tap fix rather than a red error, because that person wanted in and would otherwise have vanished. The trap is verifying on every keystroke. It burns credits and makes the field feel twitchy. One call, on submit.
2. The free trial gate
If the trial hands out credits or sending capacity, check is_disposable before you provision anything. Disposable addresses (mailboxes a throwaway service issues for ten minutes) are the easy route to a second and a ninth trial from the same person. Ask for a different address and say why: they will need it to log back in. Over-blocking is the risk here. is_free_email being true only means Gmail or Outlook, and most of your paying customers live there.
3. Inviting a teammate
Invites fail invisibly, because the person who typed the address is not the person waiting for the email. An admin types [email protected] when the mailbox is john@, nothing arrives, and you hear about it a week later through support. Verify while the invite dialog is still open and put the problem in front of the admin who can fix it. One caution: do not reject a whole corporate domain for being catch-all. Plenty of real companies run their mail that way.
4. Checkout and receipts
A mistyped billing address means the receipt never lands, and the customer chases you for it at the worst moment. Run the check when the billing form posts so the correction happens while the buyer is still on the page, and act on invalid only. Finance addresses are often role accounts (billing@, accounts@) sitting on catch-all domains, so blocking role_account or catch_all here will stop legitimate B2B purchases. Store the verdict against the order. It explains a lot later.
5. Password reset requests
Someone types an address into the forgot-password box. Either no account exists or they mistyped, and your response has to look identical either way, because confirming which one tells an attacker whether an account exists. Verification still earns a place: when the domain has no mail server, add a quiet “check the spelling” hint next to the usual “if that address is in our system, a link is on its way”. The hint is generic. The message stays generic too.
6. Lead capture and gated downloads
Gated content attracts throwaway addresses by design. Verify when the form posts, act on disposable, and deliver the asset by email instead of showing it on screen, which quietly changes the visitor’s incentive to type a real address. Do not gate on role_account, though. At a ten-person company info@ is one person who reads everything. For what junk leads do to the numbers further down, see fake emails in your funnel.
7. CRM records and bulk imports
Two shapes of the same job. A sales rep typing one contact gets a live call and immediate feedback. A spreadsheet of 40,000 rows from a trade show goes through bulk verification, where per-address waiting time stops mattering and power mode becomes affordable. The distinction is worth understanding before you build either path: real-time vs bulk email verification. The trap is re-running your whole database weekly. Addresses decay over months, so that habit mostly spends credits.
8. Contacts created by automations and webhooks
A webhook is a message one app fires at another the instant something happens, and Zapier-style flows create contacts all day with nobody watching. That is exactly why the call belongs inside the flow, before the contact is written. Route anything invalid into a review queue. The real trap is the failure path: an automation that drops records whenever the verification step errors will lose good leads silently. Retry once, then let the record through with a flag on it.
9. Re-verification before onboarding and lifecycle sends
An address verified in March can be gone by October. People change jobs, providers close accounts, mailboxes fill up. Before a long onboarding sequence or a campaign aimed at an older segment, re-verify that segment in the background with power mode, where a slow answer costs you nothing, and act on invalid, disabled and inbox_full. Keep the scope tight: re-verify the segment you are about to mail and leave the rest of the database until its turn.
10. Support tickets created by email
When tickets arrive through an email channel, or an agent types a requester address by hand, the reply-to can be wrong from the first minute, and a support reply that bounces feels to the customer like being ignored. Verify the requester address at ticket creation and flag bad ones on the ticket so the agent sees it before writing a careful answer into a void. Never block ticket creation on a verdict. A customer in trouble has to get through.
11. Marketplaces and two-sided platforms
Both sides need a working mailbox, for different reasons. Buyers need order confirmations. Sellers, drivers and hosts need payout notices and the message that says a job is waiting, which is the side where a missed email costs the most and the side teams forget to verify. Run the check on both signup paths. Run it again when either party edits their address in account settings, the moment almost nobody instruments.
12. Addresses partners push through your API
If resellers or white-label customers post addresses into your system, verify at that boundary. Their data quality becomes your sender reputation the moment you mail it. Return a clear error on invalid so the partner fixes it at their end, and keep a per-partner count of bad addresses, which turns into an early warning about where the data is really coming from. Accepting quietly and cleaning up later is how a shared sending domain gets burned.
A plain integration pattern
Five rules cover most implementations.
- Call on submit. One address, one call, at the moment the form posts or the record is created. Not on keystroke, not on blur.
- Branch on
statusfirst. Read the booleans afterwards for nuance. Then changing how you treat role accounts stays a one-line change. - Time-box it and fail open. Set a timeout of a second or two. Failing open means you accept the address when the check does not answer in time, mark the record unverified, and re-check it in a background job. A verification outage must never become a signup outage.
- Cache briefly. Hold the verdict for ten or fifteen minutes so a double-click or a retry does not spend a second credit.
- Never block on
unknownorcatch_all. You cannot prove either wrong, so let them in and watch what happens on the first real send.
The first rule depends entirely on speed. Quick mode’s 0.5 second target is what keeps the check hidden inside the submit round-trip, and we measured where that time actually goes in how fast email verification is.
The short version
| Use case | Verdict to act on | Action |
|---|---|---|
| Signup form | invalid, mx_accepts_mail false | Inline typo suggestion, let them fix it |
| Free trial gate | is_disposable true | Ask for a different address, explain why |
| Teammate invite | invalid | Show the admin before the invite sends |
| Checkout | invalid | Correction field before the charge |
| Gated download | disposable | Deliver the asset by email only |
| Bulk import | invalid, spamtrap | Quarantine the row, import the rest |
| Automation-created contact | invalid | Review queue, with a retry first |
| Pre-send re-verification | invalid, disabled, inbox_full | Suppress for this send |
| Every use case above | unknown, catch_all | Accept, tag the record, monitor |
What this cannot do for you
An email verification API checks a mailbox, so it has nothing to say about intent. Someone opening their fourth trial with a genuine Gmail address passes every check that exists, because every check is about the address. Intent is a job for rate limits, device signals and a card on file before anything valuable is released. The wider signup playbook lives in how to stop fake email signups.
Catch-all domains stay unresolved, and no vendor can fix that from outside. If a domain accepts everything, the only real proof is sending genuine mail and watching what comes back.
Then there is the dependency. Every call is a network call, and your signup path now leans on a service you do not run, which is why the timeout and the fail-open rule are not decoration. Reoon’s email verifier advertises live API validation in 0.5 seconds and states that unknown results are never charged, which takes the cost objection off the table. The dependency itself is still yours to design around.
If you want to see real verdicts before writing any code, create a free account and point a staging form at the API for an afternoon. Free credits renew daily, no card is needed, and there is a WordPress plugin if your forms already live on WordPress.
FAQ
Which mode should a signup form use?
Quick mode. Reoon’s documentation puts it within 0.5 seconds and returns the syntax, MX and disposable signals a form actually needs, which covers typos and throwaways. Power mode inspects the individual inbox and can take from a few seconds to more than a minute, so it belongs in background work like imports and pre-send cleaning, where nobody is watching a spinner.
What should my code do if the verification call times out?
Let the signup through. That is what failing open means: when the verifier does not answer inside your timeout, you accept the address, mark the record as unverified, and re-check it in a background job later. A blocked signup form during somebody else’s outage costs far more than the handful of bad addresses that slip past while the check is unavailable.
Should I block catch-all addresses at signup?
No. A catch-all domain accepts mail for every possible address, so the verifier cannot confirm or deny one specific mailbox there, and plenty of established companies run their mail exactly this way. Blocking catch_all means rejecting real customers over a decision their IT team made years ago. Accept them, tag the record, and let the first real send tell you the truth.
How often should I re-verify addresses already in my database?
Not on a fixed schedule for everything. Re-verify the segment you are about to mail, shortly before you mail it, and pay extra attention to addresses collected more than six months ago or contacts who have gone quiet. Lists decay slowly, so weekly sweeps across an entire database spend a lot of credits to learn very little that is new.
