Short answer
What to know
Choose ReqRes when a test needs to log in, page through results, wait for a delayed response or save data between requests. Choose Payloads when the code under test only reads data and you want the same records in JSON, XML, CSV and binary formats, with SHA-256 checksums and no account or API key.
The short comparison
| Need | Payloads | ReqRes |
|---|---|---|
| Read a list of sample users | Yes; 3 users | Yes; paginated demo users |
| Demo login and register | No | Yes, with fixture emails |
| Delayed responses | No | Yes, with a delay query parameter |
| Writes that persist | No | Yes, in project collections with an API key |
| XML, CSV, YAML, MessagePack, CBOR and PDF | Yes | No; JSON API |
| Published SHA-256 per file | Yes | Not its main contract |
Choose ReqRes for API behaviour
ReqRes describes itself as a hosted REST API with real endpoints, persistent data and request logs. Its demo endpoints list users page by page, return a single user, accept POST, PUT, PATCH and DELETE (echoed, not persisted) and simulate login and registration with fixture emails. A delay parameter slows a response down. Project-scoped endpoints store data for real and need an API key from its app.
Check the key rules before CI depends on them
The ReqRes home page invites you to send a real request with no signup and no key. Its documentation says every request requires an x-api-key header. A request to /api/users/2 without a key returned 200 when we checked on 14 October 2026. If a test suite must not break on an auth change, read the current ReqRes docs first.
Choose Payloads for read-only fixtures
Payloads never asks for a key and never changes a published file. It has no login, pagination or writes. Use it when the code under test reads, decodes or imports data and you want the input pinned by URL and SHA-256.