- Real-time verification, defined
- Real-time verification is a single-address check made through an API while a person waits, typically at a signup form, returning a verdict in a few hundred milliseconds.
Call it on blur rather than on submit, so the check runs while the visitor moves to the next field and the answer is already there when they finish.
Fail open, always. Set a timeout near 500 milliseconds and accept the address if nothing came back, then verify the queue in bulk afterwards and clean up what slipped through.
What you do with a doubtful result is a product decision. Blocking an invalid address is uncontroversial; blocking a catch-all is refusing perfectly ordinary corporate customers because their IT department configured a wildcard.
A typo suggestion earns more than a block does. Offering gmail.com when someone typed gmial.com recovers the signup instead of ending it.
How ZapBounce reports it
The single-address endpoint is POST /v1/verify, and it returns the same four results as a bulk run (valid, invalid, catch_all, unknown) with reason and smtp_code attached. Unknown results are not billed here either, which matters at a form because the slow, evasive domains are exactly the ones a live check meets.
What to do with each answer at the form
Say someone types dana@gmial.com into your trial signup and tabs to the password field. Your server gets the verifier's response 300 milliseconds later. What should the form do?
For invalid with a likely typo, show a gentle inline prompt: Did you mean dana@gmail.com? Let her accept it with one click or keep what she typed. With no suggestion to offer, ask her to check the address and let a second attempt through, because any verdict can be wrong and a blocked customer is gone.
catch_all and unknown both mean accept and move on. Flag the record, and let your confirmation email settle the question. A role flag on info@ is worth a soft nudge in a B2B product (A personal work address helps us reach you), and nothing more than that.
Whatever you show, never echo the mail server's raw response to the visitor.
Keep the key on your server
The most common integration mistake is calling the verification API straight from browser JavaScript. Your API key is then visible to anyone who opens developer tools, and someone will copy it and spend your credits on their own list. Route the call through a small endpoint on your own server, and have that endpoint hold the key.
That endpoint is also where the protections go. Limit requests per visitor session, since nobody needs to check more than a few addresses while filling in one form. Cache the result for each address for the length of the session, so a visitor who clicks in and out of the field five times costs you one check.
Debounce on the client as well. Wait until the field loses focus, and skip the call entirely when the text has no @ or no dot after it. Those cases fail a free syntax check in the browser and don't need a network trip. What's left is the traffic worth paying for: complete addresses, typed by real visitors, checked once.
Real-time verification: common questions
How fast should a form check be?
Under 500 milliseconds for a good experience. Beyond that, accept the address and verify it in the background.
Should I block catch-all addresses at signup?
Usually not. Catch-all is a corporate mail configuration, and blocking it turns away businesses rather than bad data.
What if the verification API is down?
Accept the signup. A failed check should never cost you a customer; queue the address and verify it later.