API Schema Validation compares supplied request and response examples with a specific interface contract. The result depends on the schema dialect, operation, direction, and reference context; an unresolved contract is not a pass.
Identify the dialect and operation first
Record whether the contract is OpenAPI, JSON Schema, or GraphQL, including its version or dialect. Identify the operation, request or response direction, content type, reference root, and resolution context. If a version-dependent rule or reference cannot be established, leave that judgment pending.
Separate missing, null, and constrained values
Evaluate each sample against the actual schema instead of treating similar-looking inputs as equivalent.
| Sample condition | What to inspect |
|---|---|
| Property absent | Whether it is required in this operation and schema branch |
| Property present as null | Whether null is allowed by this dialect and type declaration |
| Value has wrong type or range | The applicable type, bound, and schema path |
| Format or enum | Declared format, validator support, and allowed enum values |
| Unknown property | The schema’s additionalProperties rule |
| Composed or referenced schema | Resolved reference, applicable branch, and dialect rules |
GraphQL uses input/output types and its non-null rules; do not apply JSON Schema keywords to it. Do not infer that an optional field accepts null, or that a default is automatically inserted.
Report sample decisions, not assumed coverage
For each supplied sample, record the schema path and keyword, the validator or report evidence if provided, and whether the sample is valid, invalid, or unassessable under that contract. Keep unresolved references and missing examples visible. A few examples can expose a mismatch but cannot establish the full contract or prove runtime behavior.
Keep schema shape within its scope
Schema validation addresses declared structure and constraints. It does not by itself prove business rules, authorization, or compatibility with every deployed client. Use API Version Compatibility Testing when the question concerns behavior across client/server versions.
Record an ASV-## finding
Capture the object, preconditions, behavior of concern, source schema path, evidence state, impact and priority, owner role, close condition, and validation method. Keep facts, evidence-backed inferences, candidate checks, and Human decisions separate.
Prepare a bounded review
Review supplied schemas, examples, and validation reports as design or static comparison. Do not execute tests, edit schema or code, assume missing rules or versions, or turn sample counts into coverage claims.
Related Skills
- API Version Compatibility Testing checks supported client/server combinations.
- API Contract Testing reviews broader producer/consumer agreements.
Install and invoke
Install the Skill:
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/api-schema-validation -g
Invoke api-schema-validation with the contract dialect and version, operation, direction, content type, reference root, supplied examples, and available validator evidence.
Source
Read the API Schema Validation prompt. It defines the ASV-## finding contract and the sample-by-constraint decision boundary.