FDA's warning letters, addressed by column number

Open fda.gov’s warning-letter search and open a browser’s network tab alongside it, and the page gives up its trick immediately: the table is not server-rendered HTML. It is populated by a JSON call to a Drupal endpoint built to paginate a search widget, not to be read by anyone’s pipeline. That is good news — a free, keyless, paginated feed of every CDRH warning letter, no scraping required. The shape of what comes back is the part worth being careful about.

An array, not an object

Every other source this instrument reads returns named fields. The Federal Register API hands back title, publication_date, cfr_references; openFDA hands back recall_number, product_code. Ask for a field by name and you get it, or an explicit null. The warning-letter endpoint returns something else entirely: each row is a bare array of eight strings, most of them small fragments of HTML, in a fixed order, with no keys attached anywhere. Position two, verified against a live row, holds the company name wrapped in a hyperlink to the letter itself. Position four holds the subject line — the closest thing this source has to a violation theme. Nothing in the response says so. That mapping exists in exactly one place: whoever last counted columns against the rendered page.

The contract nobody signed

That is a real risk, not a theoretical one. FDA is free to reorder those eight columns, insert a ninth, or drop the frequently empty excerpt field at position seven, and the endpoint will keep returning perfectly valid JSON — just JSON in a different order. Code that reads position two and calls it the company will, from the moment the order shifts, read whatever now sits in position two instead: the issuing office, say, or the subject line. It will not throw. It will attribute a warning letter to the wrong firm, confidently, for as long as nobody happens to check it against the page by eye.

A silent reorder is not a crash. It is a data set that is wrong in a way nothing downstream is built to notice.

Fail loud, on purpose

The defense here isn’t cleverness, just a shape check that runs before any field is trusted: exactly eight positions, the first two each carrying an HTML time element with a datetime attribute, the third carrying a hyperlink. Any one of those checks failing raises immediately, and the ingest run stops rather than finishing on data it can no longer vouch for. On an ordinary Tuesday — the day CDRH letters typically post — the check costs nothing; it passes and moves on, the way an assertion should. On the day the table’s shape actually changes, it is the difference between a loud failure fixed that morning and a quiet one that ships wrong company names for months before anyone reads closely enough to catch it.

Past this one endpoint

Plenty of official data behaves like this: genuinely public, free to reach, and never designed to be read by anything other than the page it renders. The Federal Register API and openFDA are documented contracts — versioned, keyed, meant to be depended on, with a published schema behind every field. A datatables endpoint behind a search box is not; it is an implementation detail that happens to be inspectable, and treating it as sturdier than that is the mistake. Which of the two a given feed actually is — contract or convenience — is worth checking before a pipeline is built on it, not after the feed has quietly answered the question itself. That check is an engineering habit, not a regulatory judgment call; it is also the only thing standing between a monitoring product and a warning letter filed under the wrong company’s name.