Keep your parser alive when the API adds a field

A JSON feed does not stay frozen. Fields get added, market types multiply, and an enumeration gains a member you have never seen. If your parser treats every surprise as fatal, your pipeline falls over on a quiet Tuesday when nothing else is wrong. The working rule is older than JSON: require the fields you use, tolerate everything else.

Additions are not breakage

An API that adds a field to its event objects has broken nothing. The events array is still there, the cursor is still there, and every field you read still means what it meant. The failure only happens if your code insists on knowing every key in advance, for example by deserializing into a rigid record type that rejects unknown members, or by asserting a fixed set of market names.

The error handling runbook already draws the line for the other direction: require the documented envelope, the events array and the cursor, before touching the payload. That requirement is about what must be present. Forward compatibility is about what may also be present.

Two rules for a tolerant parser

First, read by name, never by position or by exhaustive listing. Fetch the fields your logic needs and ignore the rest; a parser that iterates over every key and switches on each one will meet a key it cannot switch on.

Second, validate values, not vocabularies. Check that the price is a number above one, that the timestamp parses, that the event id is present. Do not check that the market name belongs to a list you wrote in March, because the list is the part that ages. The runbook's warning about nulls applies here too: a null price means the market is closed or unavailable, and the correct response is to keep it null, never to substitute zero.

Log the drift without failing on it

Tolerance does not mean blindness. When your parser meets a field or a value it does not know, count it and move on. A debug-level line or a counter per unknown key is enough. Once a week, read the counts: they tell you what the feed added, which is often a feature you now get to use, like a new market type you can start storing.

This is the difference between drifting and breaking. Drift is the feed growing around you; breaking is your code refusing to grow with it.

Pin the contract with fixtures

A handful of recorded responses in your test suite turns the policy into a check: the parser must accept the recorded envelopes, extract what you use, and shrug at a synthetic event carrying invented extra fields. When the feed documents a genuinely breaking change, that is a migration to plan, not a surprise to survive. Until then, tolerance is the plan.

Require the envelope, read by name, log the unknown. A parser built that way only breaks when the world actually changes, not every time the feed learns a new word.