GET /account is where you check what your key is configured to do before you debug why a result looks odd. Retention window, default timeout, whether catch-all probing is on, and the webhook URL every batch inherits.
Two of these settings change results rather than plumbing. smtp_timeout_ms decides how long we wait on a slow server before calling it unknown, and catch_all_probe decides whether we test the domain with a random address at all. Turn the probe off and catch-all domains come back as valid, which will make your summary look better and your next send worse.
Settings are per key, so your staging key can run a short timeout and your production key a patient one.
curl https://api.zapbounce.com/v1/account \
-H "Authorization: Bearer zb_live_..."{
"account_id": "acc_5d11b2",
"key_label": "production",
"mode": "live",
"settings": {
"retention_days": 30,
"smtp_timeout_ms": 8000,
"catch_all_probe": true,
"default_webhook_url": "https://yourapp.com/hooks/zapbounce"
},
"created_at": "2026-08-02T14:20:00Z"
}Fields
| Field | Type | What it carries |
|---|---|---|
| retention_days | integer | How long results and uploaded files are kept. 0 means delete as soon as you have downloaded. |
| smtp_timeout_ms | integer | Patience per probe. Lower it and more slow servers become unknown, which costs coverage and saves nothing. |
| catch_all_probe | boolean | Leave it on. Off is how a summary starts lying to you. |
| mode | string | live or test, derived from the key prefix. Read-only. |
One signup key and one bulk key
Say you use the API in two places. A signup form has a person waiting, so its key carries a short smtp_timeout_ms, perhaps 3000. Your weekly cleaning job has nobody waiting, so its key keeps a patient 8000. You get quick answers where speed matters and better coverage where it doesn't.
You can see the trade on your own data. Take a sample of 1,000 addresses, run it once on each key, and compare coverage on the two batches. We'd expect the short-timeout key to show more unknowns, because slow and greylisting servers run out of time before they answer. We won't quote a figure for that gap, since it depends on the mail hosts in your sample.
Give each key a key_label that says what it's for. When a result looks odd three months from now, that label tells you which settings produced it.
A config check at the top of every job
Settings live on the key, and anyone with dashboard access can change them. Finished results keep the settings they ran under. A wrong setting is cheap to catch before a job and impossible to fix after one.
So start each job with GET /account and four assertions. mode is live. catch_all_probe is true. retention_days matches what your data agreement says. default_webhook_url points where you expect. If any of them fails, stop the job and tell someone.
The probe check earns its place. With the probe off, addresses on accept-all domains come back as valid and flow straight into your main send. On a business list that can be a quarter of your file. You'd learn about it from your bounce report, days after the damage.
The mode assertion catches a quieter slip: a test key deployed to production, where every address gets a scripted verdict and nothing looks broken.
Questions developers ask
Can I set retention to zero?
Yes. Results live only as long as the batch takes, and you download them or lose them. Some buyers need exactly that.
Why would I lower the SMTP timeout?
Real-time signup checks, where a person is waiting. For bulk work a shorter timeout just converts slow answers into unknowns.
Are settings shared across keys?
No. Each key has its own, which is what makes a cautious staging configuration possible.