Health care supplies data: the clearance, the recall and the five-million-record device catalog. · Head-to-head
openFDA Device 510(k) Clearances API vs openFDA Device Recalls API
Which health care supplies data: the clearance, the recall and the five-million-record device catalog. data fits your job: openFDA Device 510 Clearances API, or openFDA Device Recalls API. API, files, or your warehouse. Daily, weekly, or hourly.
openFDA Device 510(k) Clearances API
openFDA Device Recalls API
Where the fields line up
7 shared fields — join on these.
| Field | openFDA Device 510 Clearances API | openFDA Device Recalls API |
|---|---|---|
product_code | Three-letter product code identifying the device type (classification panel). | Three-letter FDA regulation product code for the device type. |
address_1 | Primary street address of the applicant. | Primary street address of the recalling firm. |
address_2 | Secondary address line of the applicant. | Secondary address line of the recalling firm. |
city | City of the applicant's address. | City of the recalling firm. |
state | State postal code of the applicant's address. | State of the recalling firm. |
postal_code | Postal code of the applicant's address. | Postal code of the recalling firm. |
openfda | Harmonized annotation block including fei_number, registration_number, regulation_number, device_class and medical_specialty_description. | Structured text field. Harmonized annotation block joined by openFDA where the device could be resolved. |
Coverage, side by side
| openFDA Device 510 Clearances API | openFDA Device Recalls API | |
|---|---|---|
| Geographic | Devices marketed in the United States; applicants domestic or foreign, with country code captured (US, IL and others) | United States recalls, with `distribution_pattern` naming the states and territories reached, international shipments included |
| Temporal | 1976 to present - roughly five decades of premarket notifications; 175,814 records observed at the August 2026 data load | Recalls classified since November 1, 2002; firm-initiated corrections added from January 3, 2017; 58,999 records observed at the August 2026 load |
| Granularity | One record per premarket notification submission | One record per recall event and product registration entry |
What each contains
They tie on 1 attribute. Pick by fit, not by loyalty.
| openFDA Device 510 Clearances API | openFDA Device Recalls API | |
|---|---|---|
| Geography | Devices marketed in the United States; applicants domestic or foreign, with country code captured (US, IL and others) | United States recalls, with `distribution_pattern` naming the states and territories reached, international shipments included |
| Temporal reach | 1976 to present - roughly five decades of premarket notifications; 175,814 records observed at the August 2026 data load | Recalls classified since November 1, 2002; firm-initiated corrections added from January 3, 2017; 58,999 records observed at the August 2026 load |
| Granularity | One record per premarket notification submission | One record per recall event and product registration entry |
| Unit of analysis | The submission: who filed, what the device is, what FDA decided and when | The event: who recalled, which units are affected, why, and what happened next |
| Scale | 175,814 notifications across a 24-field dictionary | 58,999 recall events across a 29-field dictionary |
| Outcome vocabulary | Decision codes with plain-language descriptions (SESE, Substantially Equivalent) and review pathway types | Recall status (Ongoing, Completed, Terminated) plus categorized root causes (Device Design and others) |
Or take both in one feed
They meet exactly once per device type, and the meeting point is productive. Both dictionaries key on the FDA's three-letter product codes, so a category like KPS imaging systems or MGQ wound dressings can be profiled end to end: how many new entries cleared into the code over time on the 510(k) side, and how many corrections were pulled back out of it on the recall side. A supplier-screening team reads the ratio the way an underwriter would - categories with heavy recall traffic relative to clearance volume get harder questions before onboarding.
Two practical notes from the records. Join through k_numbers deliberately - recall rows cite K-numbers only where the implicated device was 510(k)-cleared, so PMA-regulated products leave the bridge empty, and absence of a link is not evidence of absence of risk. Datadory delivers either daily, weekly, or hourly - your call. Or take both in one feed.
API, files, or your warehouse. Daily, weekly, or hourly.
Fair questions
Can I track one company across both datasets?
Yes, with name discipline. Each side carries a full address block - city, state, postal code and country on both, plus FEI number on the recall side and contact details on the clearance side. Names drift between filings, so normalize on identifiers where they exist and confirm borderline matches by address before treating two spellings as one firm.
What can these two datasets tell me about a product category?
Entry rate and failure rate together. Filter either side by product code - LPL contact lenses, KPS PET/CT scanners, MGQ wound dressings - to see how many devices cleared into the category over time and how many recalls came out of it, with root causes categorized and distribution patterns mapped by state. The pairing turns a regulatory archive into a category risk profile.
How does Datadory deliver these two datasets?
Both arrive through the same Datadory pipeline with verified field dictionaries, sample rows and documented coverage, delivered daily, weekly, or hourly - your call. Sample each against your own questions, then take either one alone or both in one feed.