Validate signup emails from your backend without losing users
You're building the registration flow and someone asked for email validation. The HTTP call takes ten minutes to write. The choices around it decide whether it protects your list or quietly costs you users.
This call is unusual. ZapBounce opens a live SMTP conversation with a stranger's mail server, so that server sets the timing. Design for a slow reply from day one and the check never touches your signup speed. The single verification docs list every field it returns.
The order the work happens in
Run the free checks in your own code first
Shape, a typo hint and an MX lookup catch many real errors in milliseconds. Anything that fails syntax never costs a ZapBounce credit anyway, so these checks save you round trips, not money.
Call the API outside the request path
Create the account, then verify from a background job. The new user never waits on somebody else's SMTP server, which is the failure this design exists to prevent.
Pick a timeout and decide what it means
For a background job, a ten-second client timeout is a sensible ceiling. When it expires, store the row as unresolved rather than invalid, because a timeout describes the network, not the address.
Store the result, the reason and the date
Keep status, reasonCode and checkedAt in their own columns. A verdict is evidence with a shelf life, and a true-or-false flag with no date is worthless in six months.
Retry without paying twice
Back off on a 429 for the number of seconds in the X-RateLimit-Window-Seconds header, and send an Idempotency-Key with each job submission. ZapBounce honours the key for 24 hours, so a retried submission never bills twice or creates a second job.
Build against a handful of addresses
Test keys that start with zb_test_ behave like live keys, so calls spend credits. Wire up your parsing, retries and storage against a few addresses, then run at volume.
What each result means here
The same four results and their flags, read against this job. A catch-all worth keeping in one situation is one to exclude in another.
| Result | What to do with it |
|---|---|
| Valid | Store it with the date. The user sees nothing. |
| Invalid | Ask for a corrected address at next login, and offer your own suggestion when the domain looks like a common provider. Keep the account. |
| Catch-all | Store it as unconfirmed. Business users land here often, and they're usually your best accounts. |
| Unknown | Store it with the reasonCode, such as TEMPORARY_FAILURE or TIMEOUT, and re-check on a schedule. It costs nothing. |
| Role flag | Store the flag. It's fine on a B2B product and worth a question on a personal account. |
| Disposable flag | The one flag worth acting on at signup, and only where a throwaway account costs you money. |
How you know it is finished
A signup takes the same time it did before the integration, every account carries a result, a reason and a date, and no branch in your code turns an unresolved result into a rejection.
Worth planning for
Signup volume is small next to list cleaning, so most products fit inside the 100 free credits a month plus a $5 top-up for 1,000. Credits never expire, and unknowns, duplicates, errors and rate-limited calls are never billed. The API overview covers keys and limits, and pricing has the full table.
Questions people ask
Should an email validation API call block user registration?
No. Create the account, verify in the background, and fail open on a timeout. Blocking a registration on another company's mail server turns their setup into your lost user. The one result worth acting on right away is a disposable flag, where throwaway accounts cost you money.
What should my code do with an unknown result?
Accept the account, store the reason and re-check later. An unknown means the receiving server wouldn't answer, which is a fact about that server rather than the person signing up. ZapBounce doesn't bill it.
How long should a verification result be trusted?
Store the date and decide per use. For a transactional address a few months is reasonable. Before a large marketing send to the same records, check again.
Can I test the email validation API without spending credits?
Yes, within the free allowance. Every account gets 100 free credits a month, and keys that start with zb_test_ behave like live keys, so build your parsing, retries and storage against a handful of addresses first.
Try it on the file in front of you
100 free checks a month, no card. Addresses we could not get an answer on come back labeled as unknown, and those are not billed.