Skip has a ceiling. Search after doesn't.

A broad pull against openFDA looks like it is working — page after page, no errors, more records on the way — until the twenty-six-thousandth one arrives and the next page simply is not there. Nothing crashed. The query was not wrong. FDA’s own paging documentation says plainly why: skip-and-limit paging has a ceiling, and a script built around those two parameters alone has no way to ask for what sits past it.

The number FDA actually publishes

openFDA pages a result set with limit, the records returned per request, capped at 1,000, and skip, how many records to skip before the next page starts, capped at 25,000. The two caps compound: the deepest page a skip-and-limit walk can reach starts at skip 25,000 and returns up to 1,000 more, for a ceiling of 26,000 records reachable through that pair of parameters on any single query, full stop. FDA states both numbers on its own paging documentation, as the boundary of what the parameter accepts, not as a number that happens to come up often in practice.

Where a device query actually meets it

Twenty-six thousand sounds generous until the query is broad rather than narrow. Every device enforcement report naming a high-volume product code across several years, every 510(k) decision under a classification that clears hundreds of devices a year, or every adverse event report citing a widely used predicate can clear that number before the history runs out. A script that only knows skip and limit does not announce the moment it happens. It simply stops being able to ask for the next page, and a monitor nobody told about the ceiling has no reason to notice the record it is missing.

A result set that stops at 26,000 is not telling you the recalls stopped. It is telling you the parameter did.

What exists past the ceiling

openFDA documents a way past it, and it is not a bigger number for skip. search_after pages by cursor instead of offset: the response carries aLink header with the exact URL for the next page, and following it can walk a result set of any size, up to the full dataset. The two paging styles do not mix — a request cannot send search_after alongside skip and expect either one to behave. For a pull broad enough that paging itself is the wrong tool, openFDA also publishes each dataset as downloadable files, meant for exactly that case rather than for a few thousand more pages.

The practice

A query built to run once and read a known answer — this quarter’s recalls for one product code, one applicant’s clearances this year — rarely comes near 26,000. A query built to run unattended against a broad search is a different program, and the response’s own meta.results.total field states the full size of the match before a single page is read — worth comparing against 26,000 before paging starts, not after a page quietly fails to appear. FDA Radar’s own ingestion sidesteps the question rather than solving it cleverly: every pull is bounded to a recent date window, seven days by default and wider only for an explicit backfill, so a skip-and-limit walk never approaches a ceiling built for a query with no end in sight. That is a design choice suited to a daily monitor, not a workaround — the ceiling is real for anyone building a broader pull than ours, and this is regulatory intelligence about how one public API is documented to behave, never a claim about what any specific device count means. See what we source and how often for the rest of the pipeline.