API documentation

One endpoint does most of the work. Everything else is batching, billing and getting told when a long job finishes.

Shell
curl -s -X POST "https://api.zapbounce.com/v1/verify" \
  -H "Authorization: Bearer $ZAPBOUNCE_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email":"ada@example.com"}'

{
  "email": "ada@example.com",
  "result": "catch_all",
  "reason": "accept_all_domain",
  "domain": "example.com",
  "mx_found": true,
  "mx_host": "mx1.example.com",
  "smtp_code": "250",
  "role": false,
  "disposable": false,
  "free_provider": false,
  "did_you_mean": null,
  "billed": true,
  "checked_at": "2026-09-18T10:02:41Z"
}

Every response carries a result, a reason from a fixed list, the mx_host we spoke to with its literal smtp_code, and whether the check was billed. An address we could not get an answer on comes back as unknown with billed: false. The three booleans, role, disposable and free_provider, are flags about the address and never results.

The four verdicts

These are the only values the result field takes. Branch on them. The reason list underneath can grow, so treat a reason you don't recognize as extra detail.

valid

Valid

The mailbox accepted the address at the SMTP step.

invalid

Invalid

The server rejected the address outright.

catch_all

Catch-all

The domain accepts every address, so the mailbox cannot be confirmed.

unknown

Unknown

The server would not give a straight answer. We say so, and we do not bill it.

Reference

Account endpoint

GET /account returns the settings that change how verification behaves for your key: retention window, catch-all handling, timeout budget and webhook defaults.

API authentication

How to authenticate against the ZapBounce API: bearer keys, where to keep them, how to rotate one without downtime, and why a key in a query string is a leak.

API changelog

What changed in the ZapBounce API and when. The log starts at public launch, and additive changes are recorded here alongside breaking ones.

API error codes

Every HTTP error the ZapBounce API returns, what actually went wrong, whether a retry will help, and why an error never costs you a credit.

API rate limits

Per-key request limits, the headers that report your remaining budget, and the backoff behavior that keeps a retry storm from making your own results worse.

API uptime

We publish no uptime figure yet, because we have not been running long enough to have measured one. Here is exactly what we will publish and how it gets calculated.

API versioning

The ZapBounce API is versioned in the URL path. What counts as a breaking change, what we ship without warning, and how long an old version stays up.

Batch status endpoint

GET /batches/{id} reports progress and the verdict breakdown for a running or finished batch, including the count we could not resolve and did not bill.

Bulk verification endpoint

POST /batches submits up to 100,000 addresses for background verification. How batching works, how duplicates are handled, and what the summary counts mean.

Credits endpoint

GET /credits returns your balance and recent ledger. What consumes a credit, what never does, and how to wire a low-balance alert before a batch stalls.

Data retention API

Set how long ZapBounce keeps your addresses and results, from thirty days down to delete-on-download, and delete a batch from the API the moment you are finished.

File upload endpoint

Upload a CSV or TXT list for verification without holding it in memory. Column detection, header handling, encoding, and how the cleaned file comes back.

GDPR deletion requests

How to action an erasure request for one person across every batch, what the API returns as proof, and the honest boundary of what a processor can delete for you.

Idempotency keys

Send Idempotency-Key on a batch submission so a retried request never creates a second batch or spends credits twice, even when the first reply was lost.

Paginating results

Batch results paginate with an opaque cursor rather than offsets, so a long download stays consistent while the batch is still writing rows behind you.

Sandbox mode

Test keys return shaped verdicts without opening an SMTP connection or spending a credit. Reserved addresses force each result and each flag, including unknown.

Service status

Where to check whether the ZapBounce API is degraded, what we treat as an incident, and why slow probes against one mail host are not one.

Single verification endpoint

POST /verify checks one address in real time: syntax, MX, SMTP handshake and a catch-all probe. Response fields, timing, and what the endpoint refuses to guess.

Verification result codes

The four results ZapBounce returns and the three flags beside them: the SMTP reply behind each one, which are billed, and what each does and does not prove.

Webhooks

Get a POST when a batch finishes instead of polling. Event shape, signature verification, retry schedule, and how to make your handler safe against replays.

Before you build against this

Get a key and try it

100 free checks a month, no card.