JSON schema validation at an API boundary

JSON syntax only proves that text can be parsed. The application still needs a contract for fields, types, values and additional properties.

Validate three payloads

The engineering foundations lab accepts exactly one fixture.

from engineering_cases import json_validation_case

result = json_validation_case()
assert result["results"] == [True, False, False]
assert result["accepted_indices"] == [0]
assert result["coercion_used"] is False

One payload sends amount as text; another adds debug. Both fail before processing.

Define required and optional fields, types, formats, enum/range constraints and additional-property policy. Version contracts when compatibility changes. Avoid silent coercion for identifiers, money and booleans because it can hide caller defects.

Schema validity is not business validity. After parsing, check tenant authorization, order state, currency and totals. Validate outbound provider responses too, then map errors to safe stable client codes.

The FDE for Freshers course connects JSON contracts to Pydantic/FastAPI and integration tests.

Exercise

Create a schema with nested line items. Test missing, extra, null, negative, oversized and wrong-type cases and document one backward-compatible change.

Continue learning

This article is part of the FDE engineering foundations sequence. Use the neighbouring tasks when you need the prerequisite or the next application.

• Review the prerequisite or neighbouring task in HTTP status codes in a client-facing service.
• Continue with Build a queue-backed task with visible status.

Reference: JSON Schema documentation.