OpenFDA and eCFR: The APIs That Put Regulatory Data at Your Fingertips

In June 2014, the FDA launched OpenFDA: a free, public API that makes FDA datasets available in structured, machine-readable formats. The project was created by Taha Kass-Hout, the agency's first Chief Health Information Officer, and was part of a broader federal push toward open data in the early 2010s.

Separately, the Office of the Federal Register now maintains a REST API for the eCFR (electronic Code of Federal Regulations), giving programmatic access to the full text of federal regulations including Title 21, which governs food, drugs, and medical devices.

Together, these two APIs represent a meaningful shift in how regulatory data is distributed. What used to require Freedom of Information Act requests, manual database searches, or bookmarking PDF documents is now available through standard HTTP endpoints that return structured JSON.

Here's a practical look at what each one offers.

What OpenFDA Exposes

OpenFDA provides search-based API endpoints across several categories. For medical device and pharmaceutical companies, the most relevant ones include:

• Device clearances — 510(k) and PMA approvals, searchable by applicant, product code, decision date, and advisory committee
• Device and drug recalls — enforcement reports with classification, distribution scope, and reason for recall
• Adverse events — MAUDE reports for devices and FAERS reports for drugs, including patient outcomes and device problem codes
• Drug approvals — NDA/ANDA data, active ingredients, routes of administration, and labeling

No API key is required. You send a GET request, and you get JSON back.

For example, a search for recent 510(k) clearances from a specific company looks like this: GET https://api.fda.gov/device/510k.json?search=applicant:"medtronic"&limit=5

That returns the five most recent clearances with decision dates, product codes, device names, and review panel information the same data available through the FDA's own search tools, but in a format that's easy to filter, aggregate, and integrate into other systems.

The adverse event data is especially deep. MAUDE reports for devices go back years and include device problem codes, patient outcome categories, and manufacturer narrative descriptions. FAERS data for drugs includes reported reactions, suspect drugs, and reporter qualifications. Within months of launching in 2014, OpenFDA had already handled nearly 2.4 million API calls to the adverse events dataset alone.

What the eCFR API Exposes

The eCFR API is less well-known but equally significant. It provides access to the full text of the Code of Federal Regulations as structured data — not just PDFs, but queryable content organized by title, chapter, part, and section.

For regulated industries, this means Title 21 (Food and Drugs) is available programmatically. You can:

• Pull the current text of a specific regulation (e.g., 21 CFR Part 820 — Quality System Regulation)
• Search across titles for references to specific terms
• Access point-in-time snapshots of the CFR going back to January 2017, which is useful for understanding when specific regulatory language changed

Like OpenFDA, no API key is needed. The data originates from the same XML files the Government Publishing Office uses to produce the print and PDF editions.

What This Means in Practice

These APIs create some practical possibilities that weren't realistic before:

Continuous monitoring. Instead of periodically checking the FDA website for new clearances or recalls in your product area, you can query the API on a schedule and surface changes as they happen — filtered to the product codes, companies, or device types you're tracking.

Trend analysis. With structured data spanning years, you can aggregate recall counts by product category, track adverse event trends over time, or analyze FDA enforcement patterns. This kind of longitudinal analysis is difficult to do manually but straightforward with an API and a database.

Regulatory cross-referencing. When the regulations themselves are available as structured data, you can programmatically link SOPs or quality system procedures to specific CFR sections, and flag when those sections are updated.

Post-market surveillance. Adverse event data from MAUDE and FAERS can be queried by device type or drug name, making it possible to build ongoing surveillance workflows rather than relying on periodic manual reviews.

The Practical Constraints

It's worth being realistic about the limitations:

Rate limits. OpenFDA enforces query limits to ensure equitable access. For heavy use cases, bulk data downloads are available as zipped JSON files.

Data quality. Adverse event reports are submitted by manufacturers, healthcare professionals, and consumers with varying levels of detail. The data reflects what was reported, not necessarily what was clinically confirmed.

No real-time data. Both APIs are updated on a schedule → they reflect published data, not pending submissions or internal FDA deliberations.

Raw output. The APIs return structured but raw data. Turning that into actionable intelligence — flagging what matters for your specific product category, summarizing trends, routing alerts to the right people requires application logic on top of the API.

Worth Exploring

If you work in quality, regulatory affairs, or engineering at a biotech or medtech company and haven't looked at these APIs yet, they're worth spending an afternoon with. The OpenFDA documentation is well-organized with interactive examples, and the eCFR developer resources include interactive API documentation with endpoint details.

The data is public, the access is free, and the barrier to entry is essentially a web browser and some curiosity.