Why a 200 OK response can still break a script that reads JSON

A 200 OK response can still break a script when the JSON shape, content type, pagination, or empty-state behavior changed from what the script expects.

Scripts often trust the happy path too much. They read data.items, assume id is a number, expect an array to exist, or parse a nested value without checking whether the field is missing. The HTTP status only says the request was accepted and handled. It does not prove the response still matches the parser’s assumptions.

Debug by saving the raw response before the failing parse. Check content type, top-level keys, error envelope, pagination keys, null versus empty array, id type, and whether the API wrapped the object in data. If the response is HTML or a login page with status 200, the script may be unauthenticated even though the status looks successful. If the response is valid JSON but a field moved, the problem is response shape drift.

The fix is not only adding optional chaining everywhere. Add explicit checks around the fields the script truly needs, write a small sample response fixture, and log a clear error when the expected shape is missing. For recurring scripts, store one known-good response example so future changes can be compared quickly.

The practical rule: status code first, raw body second, shape third. Never debug a parser from the exception message alone.

Why a 200 OK response can still break a script that reads JSON

// COMMENTS

ON THIS PAGE