tldr: API schema validation enforces request and response shapes against a contract like OpenAPI or GraphQL SDL. It catches breaking changes (missing fields, type changes, removed endpoints) before they ship.
What schema validation does
Two checks.
Provider-side. Does the API actually return what the contract says it returns? Run against a deployed API; if a response does not match the schema, fail.
Consumer-side. Does the consumer code handle every shape the contract permits? Especially the optional fields and error responses.
Together they form a contract test. The contract is the source of truth; both sides verify against it.
OpenAPI and JSON Schema
For REST APIs, OpenAPI (Swagger) is the dominant standard. The schema defines:
- Endpoints and methods
- Request body shape
- Response body shapes per status code
- Required vs optional fields
- Allowed values
Tools that validate responses against OpenAPI: Dredd, Postman, Schemathesis. CI integration is straightforward.
JSON Schema underlies OpenAPI and can be used standalone for non-REST APIs.
GraphQL schema validation
GraphQL has built-in schema validation: every query and response is checked against the schema definition language (SDL). Most validation happens at the server.
For consumer-side validation, tools like graphql-codegen generate types from the schema. The compiler then catches consumer code that does not match.
What schemas catch
Breaking changes. A field was renamed or removed. Schema validation fails before the code reaches production.
Silent type changes. A number became a string. Often not caught by E2E tests because the value still appears.
Missing required fields. A required field is absent in the response. Consumer crashes.
New required fields. Adding a required field to a request without backward compatibility breaks existing consumers.
What schemas miss
Semantic correctness. A schema can say "totalAmount: number." It cannot say "totalAmount must equal sum of lineItem.amount." Semantic checks need actual tests.
Authorization rules. Schemas describe shape, not who can call what. Authorization needs separate testing.
Performance. Schemas say nothing about response time.
Schema validation is necessary, not sufficient.
How AI testing fits
For pure API contract validation, dedicated schema-validation tools are stronger than AI platforms. Bug0 covers the user-facing flow. Pair with schema-validation tooling in CI for the API contract layer.
FAQs
Should schemas be hand-written or generated?
Either works. Hand-written gives more control. Generated stays in sync with the code automatically. Most teams generate from the implementation.
What about backward compatibility?
Add fields as optional, never remove fields without a deprecation cycle, never change field types. These are the rules that keep consumers working.
How do schemas relate to contract testing?
Schema validation is a form of contract testing. Pact and similar tools add consumer-driven contract tests on top.
How does Bug0 fit?
Bug0 tests user-facing flows. Schema validation runs at the API layer in your CI. Both layers are useful.