How an API Response Changes Shape Without Anyone Noticing
Nothing throws an error. Deploys go out clean, tests stay green, the JSON still parses fine — and three weeks later, someone finds a null where a number should be, deep inside a report nobody checked closely. Schema drift is quiet by nature: nothing about a changed field shape looks like a bug from the producing side, because from that side, nothing broke.
How it actually happens
A backend team renames a field to match a database migration, and the old name simply stops appearing — no error, just an absent key wherever the old name was expected. A type narrows or widens: a field that used to be an integer starts arriving as a string once it moves through a new serialization layer, or a nullable field that was previously always populated starts showing up as null after an optional feature ships. A third-party API adds a new enum value nobody downstream expected, and code with a hardcoded switch statement silently falls through to a default case instead of erroring. Every one of these produces syntactically perfect JSON. None of them break a parser.
Why it stays invisible so long
Code that reads a specific field and expects a specific type usually doesn't check — it assumes, because checking every field on every read is tedious and most of the time the assumption holds. A missing field often means undefined gets used somewhere silently rather than throwing; a wrong type frequently coerces just well enough to avoid an immediate crash (a stringified number still sometimes works in arithmetic, a null occasionally passes a loose truthiness check) while still producing a subtly wrong result further downstream. The failure mode isn't a crash — it's wrong output that looks plausible enough not to get double-checked.
Where it tends to surface first
Reports and dashboards built from API data are a common first place drift becomes visible, since a wrong number there just looks like a business change rather than a technical bug. Data pipelines that batch-process records from an external source are another — one shape change upstream corrupts every downstream row until someone traces it back. Integration tests that mock the API response are a false safety net here: the mock reflects the shape the developer assumed when they wrote it, not the shape the real API is currently sending, so drift on the live side sails right past a passing test suite.
Catching it before it reaches production
The fix is validating shape, not just syntax, at the boundary where external data enters your system — checking a sample of real responses against a schema that encodes what you actually expect, rather than trusting that "it parsed" means "it's fine." This is cheap to do periodically even without wiring schema validation into a live pipeline: pull a batch of recent API responses or export rows, run them against a schema in one pass, and see what actually violates your assumptions right now, today, before it's a mystery bug in a report.
Check a batch now
FreeToolDev's bulk JSON Schema validator checks several documents against one schema in a single pass — paste a handful of real API responses or export rows against the shape you expect, free, with no per-document limit. For the difference between this and a plain syntax check, see this post.