An API client depends on more than a successful status code. It may rely on field names, optional values, pagination links, and error shapes that can change independently of the caller.
Choose fixtures that expose assumptions
- Include one minimal valid response and one response with optional fields absent.
- Represent an API error, an empty result, and an unexpected content type when those cases matter.
- Keep fixture values realistic but synthetic so tests do not contain personal or production data.
Validate the boundary
Parse the body and validate required fields before exposing it to the rest of the application. If a mock is used, remember that it checks your expectations; it does not prove that the live service still follows the contract.
Pair contract fixtures with a small integration check in an isolated environment when compatibility with the actual provider is important. Keep credentials outside test snapshots and logs.