Most API bugs that reach production are not outages. They are shape changes: a field
renamed, a number that became a string, an array that is now null when empty. A
status code will not catch any of those. A schema will.
Define what you expect
Open the Schema tab and describe the response:
{
"id": "integer, required",
"email": "string, required",
"plan": "string, one of: free, pro",
"created_at": "string, ISO 8601 date",
"teams": "array of objects, may be empty"
}
Be specific about the two things that break consumers most often — whether a field is required, and whether it is nullable. "Sometimes missing" and "sometimes null" are different failure modes and both need stating.
Validate a real response
Send the request, then validate the response against the schema. You get a pass, or a list of exactly which fields diverged and how. That list is the useful part: it tells you whether the server changed or your expectation was wrong.
Import from OpenAPI
If the API already publishes an OpenAPI 3.x spec, import it rather than retyping it. The response schemas come across directly, which also surfaces a common surprise — the documented contract and the live response frequently disagree, and validating the real endpoint against its own spec is often the fastest way to prove it.
Where this pays off
- Third-party APIs you do not control, which change without telling you.
- Webhook payloads — see testing webhooks locally.
- Your own API, checked before release, so a serializer change does not ship a breaking rename to mobile clients that cannot be force-updated.
Schemas sync across your devices when you are signed in, alongside your collections.