About this tool
Good fixtures look like production data: nested objects, nulls, money in minor units, ISO 8601 timestamps, Unicode names and partial failures. This library collects about twenty such payloads for the shapes testers meet most often, from a sign-up request and an OAuth token response to a cursor-paginated list, an RFC 9457 problem+json validation error, an order whose totals add up, a webhook event, a GraphQL response that returns 200 with errors, a 207 bulk result and a degraded health check. All data is fictional: example.com addresses, documentation IP ranges and the widely documented test card 4242 4242 4242 4242, clearly labelled as a test value.
How to use it
- Search by keyword (for example “pagination”, “422” or “webhook”) or filter by domain.
- Select a payload to read what it is good for and which endpoint it represents.
- Copy it formatted or minified, or download it as a .json fixture. The URL updates with #id so you can share a specific payload.
Sample JSON Payload Library FAQ
Can I use the payment payload against a real payment provider?
Only in the provider’s sandbox. 4242 4242 4242 4242 is a documented test number that sandbox environments accept; it is not a real card. Many providers do not accept raw card numbers from your server at all and expect tokenised payment methods.
Why are prices integers like 12616?
Storing money as integer minor units (pence, cents) avoids floating-point rounding errors. 12616 means £126.16. Check that your API documents which convention it uses.
What is problem+json?
RFC 9457 (which replaced RFC 7807) defines a standard error format with type, title, status, detail and instance members, served as application/problem+json. APIs can add extension members such as a list of field errors.