Sandbox mode is the same API with a test key. Nothing connects to a mail server, nothing is billed, and the response shape is identical, so your parsing code is exercised for real.
Reserved addresses force specific results and flags. That matters more than it sounds: the branch most teams never test is the unknown one, because in production it only fires when a particular mail host is in a bad mood. Here you can hit it on demand and find out whether your pipeline drops those addresses, keeps them, or crashes.
Point your CI at a test key and run the full suite on every commit without watching a credit counter.
curl https://api.zapbounce.com/v1/verify \
-H "Authorization: Bearer zb_test_..." \
-H "Content-Type: application/json" \
-d '{"email":"unknown@sandbox.zapbounce.com"}'Reference
| Reserved address | Returns | Use it to test |
|---|---|---|
| valid@sandbox.zapbounce.com | valid | The happy path. |
| invalid@sandbox.zapbounce.com | invalid | Suppression and hard-bounce handling. |
| catchall@sandbox.zapbounce.com | catch_all | Whether you segment these or blindly send. |
| unknown@sandbox.zapbounce.com | unknown | The branch nobody writes. Do write it. |
| role@sandbox.zapbounce.com | valid, with role: true | Your rule for info@ and sales@. |
| disposable@sandbox.zapbounce.com | valid, with disposable: true | Signup abuse rules. |
| slow@sandbox.zapbounce.com | valid after ~9s | Your client timeout, honestly. |
| ratelimit@sandbox.zapbounce.com | 429 | Backoff and jitter. |
Eight reserved addresses, eight tests of your own code
Each reserved address is a chance to assert something about your side. Send unknown@sandbox.zapbounce.com through your signup flow and check that the user record is saved and flagged for a later recheck. Then push catchall@sandbox.zapbounce.com through your list importer and confirm that the contact lands in its own segment.
Use slow@sandbox.zapbounce.com to prove your form still submits once your own timeout passes, long before the nine-second answer shows up. For backoff, ratelimit@sandbox.zapbounce.com shows that your client waits and doesn't hammer.
The invalid@, role@ and disposable@ addresses cover your blocking rules, and valid@ is the control. The role and disposable ones come back valid with their flag set to true, so assert on the flag. Write those eight tests once and they'll run free on every commit.
Assert on what your system did, and don't stop at what we returned. A test that only checks result equals unknown has tested our sandbox. Checking that the user was still created tests your product.
The gap between a sandbox pass and a live launch
Close that gap with a small live smoke test. Pick five addresses you control. Take your own and a colleague's, then a mailbox you deleted last month. Add one at a domain you know is accept-all, and one with a typo in the domain. You know the truth for all five, so you can judge the verdicts. It costs five credits at most, or nothing if your free monthly checks cover it.
Then guard against the opposite slip. A test key in production is a quiet failure, because every address gets a scripted verdict whatever you send and no error is ever raised. Your form would accept anything. Have your production service check the key prefix at startup and refuse to boot on zb_test_.
Do the same in reverse for CI. A live key in a test suite spends real credits on every commit, and you'll find out from your balance.
Questions developers ask
Does sandbox spend credits?
No, and it has no monthly cap. Run it as often as your test suite runs.
Can I use a sandbox key in staging against real addresses?
You can, but every address returns a scripted verdict regardless of what you send. For a real staging check, use a live key with a small budget.
Why is there a deliberately slow address?
Because most timeout bugs are found in production at 2am. This one is found on a laptop.