Worked testing samples
The endpoint list below documents every operation’s parameters; this overlay walks a sender-ID sandbox run the way a deliverability check actually uses it: list the networks the tester can probe → start a sender-ID test → poll the test by id. Success envelopes are{ data, meta }, error envelopes
{ error, meta } — see How to read a worked
sample. The testing routes ignore the
sandbox-key toggle — a live API key drives them, and the read paths are
operator reads rather than tenant-read operations.
Every response carries meta.request_id. Quote the request id when you
report a violation list that drifted mid-test, or a sender-ID gate that
allowed a string your route rejects.
1. List testing networks
GET /api/v1/testing/networks returns the networks the testing probe
can reach — the destination-window matrix for sender-ID and supplier
checks. Use it before you start a sender-ID test so you only probe
networks the matrix supports.
200
2. Start a sender-ID test
POST /api/v1/testing/sender-id-test starts a deliverability probe for a
candidate sender ID: the network, the ID string, and the probe window.
The result is a pending test id you poll on the next call.
200
3. Poll a sender-ID test
GET /api/v1/testing/sender-id-test/{testId} returns the test’s
current status — pending, allowed, blocked, or errored. Poll it
when the POST returned status: pending.
200
4. Errors
Errors follow the{ error, meta } envelope. The failure every
deliverability runner hits:
404 — unknown test id. A testId that was never started or a
cross-tenant poll:
404