Negative testing: every error code on demand

A test suite that only covers the happy path is testing the case that was never going to break. The catalog is built so every error is reachable on purpose: a guaranteed 500, a real rate limit, a teapot, and a fault injector that produces whatever you configure.

How to practise it

1. Call the Pizza oven endpoint for a reliable 500 and verify your client retries, falls back, or reports it — but does not hang.
2. Use the Fault Injection API to set a status code, a latency and a failure rate, then run your suite against it.
3. Separate 400 from 422: one means the request was unreadable, the other that it was understood and refused.
4. Separate 401 from 403, and 404 from 410. Each pair is routinely collapsed, and each collapse hides a real bug.
5. Inject a malformed body and confirm your client reports a parse error rather than crashing.

APIs to try it on

• Pizza Orders API — Place & track orders. Includes a guaranteed 500. (9 endpoints)
• Coffee Shop API — Drinks & orders. Home of the legendary 418. (6 endpoints)
• Protocol Lab API — Async jobs, redirects, 503/504, JSON Patch & content negotiation. (12 endpoints)
• Fault Injection API — Latency, status codes, malformed payloads & flaky responses. (4 endpoints)

Status codes involved

• 400 Bad Request
• 401 Unauthorized
• 403 Forbidden
• 404 Not Found
• 418 I'm a Teapot
• 422 Unprocessable Content
• 429 Too Many Requests
• 500 Internal Server Error
• 503 Service Unavailable

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.
• Async job testing — Start a long-running job, follow the 202 and its Location header, and poll to completion — including the failure and timeout paths.

Getting started guide · All 37 mock REST APIs