Skip to main content

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