Compared
Real-time vs. bulk email verification
Check a new address while someone fills in a form, or check stored addresses in your own job. Both use the same API; the difference is the time available and the decision you need to make.
| What you want to know | Real-time verification | Bulk verification |
|---|---|---|
| When you check | During signup, checkout or lead capture | When processing addresses already in a list or database |
| Who waits for the result | A person at your form | Your job or operator, rather than a person filling in a form |
| If the result is pending | Poll within a form deadline, then use your fallback policy | Queue retrieval by identifier and handle it within the job deadline |
| Evidence and results | Four final statuses, with action, checks and reason codes | The same fields; evidence depends on depth and observation time |
| How Emvero is called | One server-side request for the submitted address | One request per address in a loop you run |
| Handling unknown | Keep signup possible behind confirmation where appropriate | Keep unresolved rows separate for review or later checking |
Choose the moment that fits the decision
Use real-time verification when a person can still correct an address at signup, checkout or lead capture. The form needs a bounded wait and a clear next step. A clear format or mail-routing failure can prompt a correction; uncertain evidence should not become a false error.
Use bulk verification when addresses are already stored. Your script or application reads each row, calls the API and records the returned fields beside it. Emvero receives one address per request. You manage the input and output; there is no hosted CSV uploader or separate batch endpoint.
A longer wait does not guarantee a clear answer
Either workflow can receive pending. Wait for retry_after_ms, then retrieve GET /v1/verifications/{id} with the same credential. There are no callbacks. A form sets its own wait deadline; a background job can queue the identifier and retrieve it later.
Background work still needs pacing, retry limits and a deadline. A receiving server may continue to hide recipient information, so even a completed check can be unknown. Keep service errors, pending work and final address results separate. The API page explains that contract.
Choose the verification depth separately
Both workflows offer the same full and domain depths from the same credit balance. A full check can gather recipient-level evidence; a domain check stops before an SMTP probe and cannot establish an individual mailbox. The full versus domain comparison covers this choice.
The returned vocabulary stays the same, but the available evidence can change with depth, time and destination behaviour. Neither workflow guarantees delivery. Read the action and reason codes instead of treating a status as one fixed instruction.
Use both when the address has a longer life
A check during collection can catch an error while it is easy to fix. A later check can identify changes in a mailbox or domain before you rely on stored contact data. Neither check establishes marketing permission or recipient engagement.
The signup-form guide explains confirmation and corrections for someone registering now. The list-cleaning guide explains how to keep unresolved rows separate and review an existing list. Those policies can differ even when the API status is the same.
Where this shows up in a result
Reason codes from the closed vocabulary in the API response. These are the exact strings an integration writes an if against.
SMTP_GREYLISTED | Temporary SMTP deferral; a later check may help but does not guarantee a conclusive result. |
SMTP_CONNECT_TIMEOUT | Mail server did not answer in time |
Read a verification result.
See an example of status, recommended action and check evidence. Sign in to check your own address.