validating-api-responses

Validating API Responses

Overview

Validate API responses against OpenAPI schemas, JSON Schema definitions, and contract specifications to detect data integrity violations, schema drift, and backward compatibility regressions. Run validation in middleware (development/staging) or as post-deployment contract tests to ensure every response conforms to the documented API contract.

Prerequisites

• OpenAPI 3.0+ specification with complete response schema definitions for all endpoints
• JSON Schema validator: Ajv (Node.js), jsonschema (Python), or everit-org/json-schema (Java)
• Response validation middleware or test harness integrated into CI pipeline
• API test client for exercising endpoints and capturing response bodies
• Schema diff tool for detecting contract changes between versions

Instructions

1. Read the OpenAPI specification using Read and extract all response schemas per endpoint, including success responses (200, 201), error responses (400, 404, 500), and header definitions.
2. Compile JSON Schema validators for each endpoint-status combination, enabling strict mode (additionalProperties: false) to detect undocumented fields leaking into responses.
3. Implement response validation middleware that intercepts outgoing responses and validates the body against the corresponding schema, logging violations without blocking responses in production.
4. Configure validation strictness per environment: strict (fail on violation) in development/staging, warn (log only) in production, with violation metrics emitted for monitoring.
5. Add header validation to verify required response headers (Content-Type, Cache-Control, rate limit headers) match the OpenAPI specification.
6. Build a contract test suite that sends representative requests to each endpoint and validates every response field, including nested objects, arrays, enums, nullable fields, and format constraints (date-time, email, URI).
7. Implement schema drift detection that compares the current response shape against the documented schema after each deployment, alerting when undocumented fields appear or documented fields disappear.
8. Generate a validation coverage report showing which endpoints and response codes have schema validation, identifying gaps in the specification.

See ${CLAUDE_SKILL_DIR}/references/implementation.md for the full implementation guide.

Output

• ${CLAUDE_SKILL_DIR}/src/middleware/response-validator.js - Response schema validation middleware
• ${CLAUDE_SKILL_DIR}/src/validators/ - Compiled JSON Schema validators per endpoint
• ${CLAUDE_SKILL_DIR}/tests/contract/ - Contract test suite validating all endpoint responses
• ${CLAUDE_SKILL_DIR}/reports/validation-coverage.md - Schema coverage report per endpoint and status code
• ${CLAUDE_SKILL_DIR}/reports/schema-drift.json - Detected undocumented response field changes
• ${CLAUDE_SKILL_DIR}/src/config/validation.js - Per-environment validation strictness configuration

Error Handling

Error	Cause	Solution
Additional property detected	Response contains field not defined in schema	Add field to schema if intentional; remove from serializer if data leak; configure additionalProperties
Type mismatch	Field returns string instead of documented integer (or vice versa)	Fix serializer to match schema type; add type coercion test; check ORM field mapping
Required field missing	Response omits a field marked required in schema	Verify database query includes the field; check conditional serialization logic
Null value on non-nullable	Field returns null but schema does not include nullable: true	Update schema to allow null, or fix data source to guarantee non-null values
Format validation failure	Date field does not match RFC 3339 format or email field format invalid	Apply format serialization at the ORM/model level before response construction

Refer to ${CLAUDE_SKILL_DIR}/references/errors.md for comprehensive error patterns.

Examples

CI contract gate: On every pull request, run contract tests that validate all endpoint responses against the OpenAPI spec, failing the build if any response violates the documented schema.

Production response sampling: In production, validate 5% of responses against schemas (sampled randomly), emitting response_validation_failure metrics to detect schema drift caused by data changes.

Backward compatibility check: Compare v1 and v2 response schemas to verify that v2 is a superset of v1 (no removed fields, no type changes), ensuring existing consumers are not broken.

See ${CLAUDE_SKILL_DIR}/references/examples.md for additional examples.

Resources

• JSON Schema Specification: https://json-schema.org/specification
• Ajv JSON Schema validator: https://ajv.js.org/
• OpenAPI response validation best practices
• Consumer-Driven Contract Testing with Pact: https://pact.io/