Testing 202 Accepted and async job polling

202 Accepted is the status clients mishandle most, because it is a success response for work that has not happened. The Protocol Lab models the full pattern: submit, receive a 202 with a status URL, poll until the job resolves, and handle the job that fails rather than completes.

How to practise it

1. Submit a job, read the Location header from the 202, and poll it rather than assuming the work is done.
2. Poll with a sensible interval and a ceiling — a tight loop against a job that never finishes is its own outage.
3. Handle the job that completes with a failure: the poll succeeded, the work did not.
4. Check what your client does when the job outlives your overall timeout.
5. Combine with the 503 and 504 endpoints to see polling behave under an unreliable upstream.

APIs to try it on

• Protocol Lab API — Async jobs, redirects, 503/504, JSON Patch & content negotiation. (12 endpoints)
• Event Streams API — SSE events, replay cursors, heartbeats & ordering. (3 endpoints)
• Fun Data Bridge API — Seeded fixtures from schemas, inspired by fundata.dev. (4 endpoints)

Status codes involved

• 202 Accepted
• 200 OK
• 503 Service Unavailable
• 504 Gateway Timeout

Other techniques

• Pagination testing — Practise page-number and cursor pagination, and the edge cases that break clients: the last partial page, an out-of-range page, and a total count that disagrees with what you collected.
• Rate limit testing — Trigger a real 429 with Retry-After and X-RateLimit headers, and verify your client backs off instead of retrying straight into the limit.
• Idempotency key testing — Send the same write twice with an Idempotency-Key and confirm the operation happens once — the mechanism that stops a network retry becoming a duplicate charge.
• ETag and If-Match testing — Provoke a 412 Precondition Failed by writing with a stale ETag — the check that stops two clients silently overwriting each other.
• Webhook signature testing — Register a callback, trigger a delivery, verify its HMAC signature, and confirm a tampered payload is rejected.
• OAuth and JWT testing — Run real client-credentials, authorization-code and device-code flows, then test what your client does when the token expires mid-session.
• Negative testing — Provoke 400, 401, 403, 404, 409, 418, 422, 429, 500 and 503 deliberately, and check your client handles each one differently.

Getting started guide · All 39 mock REST APIs

Last updated 6 September 2026