FDA Medical Device Recall Intelligence

Search public FDA medical device recall data for healthcare compliance, supplier screening, retail risk, insurance research, product monitoring, and agent workflows. Run it from the Apify Console, the Apify API, or a scheduled automation. Each run starts with a summary and then returns normalized recall records with official openFDA provenance retained.

TL;DR

What you get. One summary row per query plus one normalized recall row per matching official FDA enforcement report. Every recall row carries recallNumber, deviceClass, recallStatus, productDescription, reasonForRecall, recallingFirm, postedDate, distributionPattern, productQuantity, codeInfo, firmCity, firmState, firmCountry, sourceUrl, retrievedAt, fieldCompletenessScore, schemaVersion, a stable id, and an agentMarkdown block an LLM can read without a parser.

What the summary adds. statusCounts, classCounts, topRootCauses, topSpecialties, openCount, and nationalDistributionCount, so one run answers "what is going wrong in this device category right now" instead of just handing back rows.

The pain it kills. Writing and maintaining your own openFDA client: query escaping, the 1,000-record page ceiling, pagination, inconsistent date formats, missing fields, and the difference between a genuine no-match and a broken parse. A valid no-match here returns an explicit zero-count summary. An unexpected empty payload fails the run and saves debug evidence instead of quietly billing you.

Who it is for. Hospital and clinic compliance teams, medical device distributors and resellers, insurers and claims researchers, product-safety and recall-monitoring workflows, and AI agents that need dependable recall facts with a source URL attached.

What does FDA Device Recall Intelligence return?

The Actor queries the official openFDA medical device recall endpoint and turns each enforcement report into a predictable dataset row. It is designed for teams that need recall numbers, device classes, statuses, product descriptions, recall reasons, recalling firms, posted dates, distribution patterns, quantities, code information, locations, and provenance without building their own openFDA client.

The first row is a summary, which reports the applied search, recall status, product code, device class, optional date range, returned count, source status, statusCounts, classCounts, topRootCauses, topSpecialties, openCount, nationalDistributionCount, and a warning that the official endpoint is queried through openFDA. Each following recall row contains a stable id, recall number, device class, status, product description, recall reason, firm, posted dates, distribution pattern, quantity, code information, and firm location, source URL, retrieval timestamp, completeness score, and agentMarkdown.

The live E2E and Cloud checks queried Class 2 catheter recalls with limit: 25, the prefilled demo input. Every run returned one summary row and 25 useful recall rows, split 18 Open, Classified and 7 Terminated. Verified record keys include schemaVersion, recordType, id, sourceUrl, retrievedAt, fieldCompletenessScore, recallNumber, deviceClass, recallStatus, productDescription, reasonForRecall, recallingFirm, postedDate, distributionPattern, productQuantity, codeInfo, location fields, and agentMarkdown.

If this actor saved review time, please leave a short review after the run: FDA Device Recall Intelligence reviews.

Why use this for product compliance and monitoring?

The Actor builds a bounded openFDA server-side query from the selected product or reason phrase, firm, device class, status, state, posted-date range, and limit. It paginates only when the requested limit exceeds one API page. The summary preserves the applied filters, record count, status counts, device-class counts, top root causes and medical specialties, open (not terminated) count, and nationwide-distribution signal.

Use it to identify records that deserve review. It does not decide whether an item in your inventory is affected, whether a listing must be removed, or whether a customer remedy is owed. Those decisions require matching official product identifiers, dates, model details, and the controlling recall notice.

Input reference

Field	Type	Default	What it controls
search	string, up to 160 characters	""	Server-side openFDA phrase match across product descriptions and recall reasons.
recallingFirm	string, up to 120 characters	""	Optional recalling-firm phrase.
productCode	string	""	Optional FDA device product code, for example DQY.
deviceClass	enum	ALL	1, 2, 3, or U for unclassified. Class 2 is the largest set at 43,426 records, then Class 1 at 9,683, Class 3 at 3,670, unclassified at 368.
recallStatus	enum	ALL	Open, Classified (13,691 records, still active), Completed (438), or Terminated (44,627).
state	two-letter string	""	Filter by recalling-firm state.
startDate	YYYY-MM-DD	omitted	Include recalls on or after this official recall date.
endDate	YYYY-MM-DD	omitted	Include recalls on or before this official recall date.
limit	integer, 1 to 250	25	Maximum number of matching recall records returned.

The date range is validated: startDate cannot be after endDate. The prefilled demo input is a real category screen that returns rows every time:

{
  "search": "catheter",
  "deviceClass": "2",
  "recallStatus": "ALL",
  "limit": 25
}

To narrow it to recalls that are still active, set recallStatus to Open, Classified. A note worth knowing before you write your integration: the FDA device recall dataset does not use the word "Ongoing" that appears in the FDA food enforcement dataset. Active device recalls are published as Open, Classified. Filtering on the wrong token returns nothing, which is a common way to build a monitor that silently reports all clear.

For a narrow current-risk screen, combine status, device class, firm, state, or dates with a low limit. recallNumber is an output field and stable external reference, not an input field in this version.

Output reference

All rows carry schemaVersion: "1.0", a recordType, a stable actor id, sourceUrl, retrievedAt, fieldCompletenessScore, and agent-ready markdown. The rows below are real output from the prefilled demo input, trimmed only for length:

{
  "schemaVersion": "1.0",
  "recordType": "recall",
  "id": "fda-device-recall-Z-0001-2024",
  "sourceUrl": "https://api.fda.gov/device/recall.json?search=product_res_number:%22Z-0001-2024%22",
  "retrievedAt": "2026-07-21T16:42:14.466Z",
  "fieldCompletenessScore": 100,
  "recallNumber": "Z-0001-2024",
  "eventNumber": "91327",
  "recallStatus": "Open, Classified",
  "productCode": "LJS",
  "deviceName": "Catheter, Intravascular, Therapeutic, Short-term Less Than 30 Days",
  "deviceClass": "2",
  "medicalSpecialty": "General Hospital",
  "productDescription": "Arrow ErgoPack, Pressure Injectable Arrowg+ard Blue Advance Central Venous Catheterization Kit",
  "reasonForRecall": "Under investigation by the firm",
  "rootCause": "Under Investigation by firm",
  "recallingFirm": "ARROW INTERNATIONAL Inc.",
  "postedDate": "2023-10-05T00:00:00.000Z",
  "distributionPattern": "Nationwide",
  "firmState": "PA",
  "firmCountry": "United States"
}

The summary row tells an automation how the run behaved before it processes recalls. This is the real summary for search: "catheter", deviceClass: "2", limit: 25:

{
  "recordType": "summary",
  "query": "catheter",
  "recallingFirm": null,
  "deviceClass": "2",
  "recallStatus": "ALL",
  "count": 25,
  "sourceStatus": "ok",
  "statusCounts": {"Terminated": 7, "Open, Classified": 18},
  "topRootCauses": [
    {"rootCause": "Employee error", "count": 12},
    {"rootCause": "Process control", "count": 5},
    {"rootCause": "Under Investigation by firm", "count": 4},
    {"rootCause": "Device Design", "count": 2}
  ],
  "topSpecialties": [
    {"specialty": "Cardiovascular", "count": 14},
    {"specialty": "Gastroenterology, Urology", "count": 6},
    {"specialty": "General Hospital", "count": 5}
  ],
  "openCount": 18,
  "nationalDistributionCount": 19,
  "errors": []
}

statusCounts is built from whatever statuses the source actually returns rather than a fixed list, so a new status value from FDA shows up instead of disappearing into a zero. openCount is every record whose status is not Terminated. Read the current summary for the real returned count and coverage indicators. Empty arrays and null values preserve what is available from the official feed, they do not mean a product is safe or unaffected.

Tutorial: monitor a product category safely

1. Choose one meaningful product-description or recall-reason phrase for search, or use recallingFirm for a firm-focused screen.
2. Add a date range when your workflow is concerned with a period. Keep the range valid and begin with a low limit while reviewing relevance.
3. Run the actor and inspect the first summary row. Confirm sourceStatus: "ok", note the returned count, and retain the openFDA warning in your audit record.
4. For each recall, send recallNumber, deviceClass, recallStatus, productDescription, reasonForRecall, recallingFirm, postedDate, distributionPattern, and sourceUrl to a review queue.
5. Verify the current FDA enforcement report and recalling-firm instructions before a supplier, inventory, or customer action.
6. Save id or the output recallNumber as the deduplication key, and retain retrievedAt as the observation timestamp.

The Actor writes AGENT_BRIEFING.md to the key-value store with the applied filters, returned count, Class 2 count, open (not terminated) count, and source status.

Worked examples from the verified output contract

1. Look up a specific official recall

Input:

{"search":"catheter","recallStatus":"ALL","deviceClass":"2","limit":25}

The local live E2E test and three consecutive private Cloud runs used this input, which is also the prefilled demo. Each run returned 25 useful recall rows plus the run summary, with statusCounts of 18 Open, Classified and 7 Terminated, openCount 18, and nationalDistributionCount 19. Each row carries the FDA recall number, device class, status, product description, recall reason, firm, dates, distribution, provenance, and a stable ID of the form fda-device-recall-<recall number>.

2. Watch a product category

Input:

{"search":"infusion pump","startDate":"2026-01-01","endDate":"2026-12-31","limit":25}

The Actor sends the phrase to openFDA across product_description and reason_for_recall, then applies posted-date boundaries on the server. Use summary.statusCounts, summary.openCount, and each record's reason and distribution fields to prioritize review.

3. Screen a supplier name

Input:

{"recallingFirm":"ARROW INTERNATIONAL","recallStatus":"ALL","limit":50}

That firm phrase matches 722 official device recall records at the time of writing. Use recallingFirm for firm-focused queries. Store recallingFirm, productDescription, deviceClass, recallStatus, postedDate, reasonForRecall, and sourceUrl with the supplier record. A phrase match is a research lead, not proof that every affiliate or product line is affected.

4. Build a healthcare compliance queue

Input:

{"search":"sterility","limit":100}

For each returned record, use recallNumber as the external reference and include productDescription, reasonForRecall, deviceClass, recallStatus, recallingFirm, distributionPattern, codeInfo, and the source URL. Add a manual comparison step for model or lot, lot, code, date, and distribution before an enforcement action.

5. Monitor recent recall activity

Input:

{"startDate":"2026-01-01","endDate":"2026-12-31","limit":100}

This returns a bounded current-period set after openFDA server-side filtering. Use postedDate, initiatedDate, terminatedDate, and retrievedAt to distinguish FDA posting, recall initiation, recall termination, and collection timing.

6. Handle an expected no-match

Input:

{"search":"unlikely exact phrase","limit":25}

An expected no-match succeeds with a zero-count summary. A malformed response, non-OK HTTP response, empty upstream feed, or invalid row shape fails instead of appearing as a reassuring empty result. Your monitor should treat those two outcomes differently.

Agent workflows and monitoring

For ongoing healthcare or supplier monitoring, run one fixed query per product family or supplier at a defined cadence. Store the summary separately from recall rows. Alert when a run fails, when a normally populated query returns an unexpected zero, or when a new output recallNumber appears.

A practical review path is:

1. Schedule an actor run daily or weekly with a fixed input and a small enough limit to review.
2. Deduplicate returned records on id or recallNumber.
3. Create a review item for new records, carrying the source URL, product description, recall reason, device class, status, distribution, and retrieval timestamp.
4. Ask a human or a product-matching service to compare the official notice against the actual model or lot, model, date, and market.
5. Record the decision outside this actor, including the official source and reviewer rationale.

An AI agent can summarize agentMarkdown, rank device classes and recall reasons, or prepare a review checklist. It must not treat a text match as authorization to remove products, issue notices, or give safety or legal advice without a controlled verification step.

Limitations and data handling

• The official endpoint is currently retrieved as a bounded openFDA JSON response. Filtering is local, so broad searches may take longer than a server-filtered API request.
• Search is text matching, not model or lot, barcode, manufacturer-entity, or model-number resolution. Matching words can produce false positives or miss differently worded notices.
• The data reflects the public FDA feed at collection time. It does not replace the full official recall notice, manufacturer communications, healthcare provider records, or a product-specific inspection.
• Some fields may be absent or incomplete in an enforcement report. A null quantity, code, address, or distribution field does not establish that the information is unavailable elsewhere.
• Date filtering uses report_date. The output keeps recall initiation and device class dates separately because they describe different operational events.
• The actor provides public-data research support only. It is not legal, device-safety, insurance, or compliance advice.

Buyer FAQ

Is this actor affiliated with the FDA?

No. This independent actor reads public FDA data. It is not affiliated with, endorsed by, sponsored by, or operated by the U.S. Food and Drug Administration.

Why does a run download a large response?

The official openFDA endpoint supports the bounded server-side search used here. The Actor exposes the applied filters in the summary and fails on malformed or unexpectedly empty successful responses.

Does a result prove my model or lot is recalled?

No. A result identifies a recall record that may warrant review. Compare model numbers, products, manufacturing dates, locations, remedy terms, and the official notice before any inventory, customer, or compliance action.

Can I filter by an exact recall number?

Not as an input in this version. recallNumber is preserved on every output row and can be used to deduplicate or join downstream. Use product, reason, firm, class, status, state, or date filters for collection.

What does a zero-result run mean?

For a valid query, it means no records matched the openFDA filters and the summary has count: 0. A source or parser problem fails the run, so it is not silently represented as a no-match.

Can I use the image and official URLs in my workflow?

They are normalized from the public response for reference. Follow the relevant source terms, keep the official notice as the controlling reference, and do not imply that FDA assets or links endorse your product or service.

What should I use as a deduplication key?

Use id or the output recallNumber. Preserve retrievedAt separately because FDA source content can change after the first observation.

Can an AI agent act on the output automatically?

An agent can triage, summarize, or create a human-review task. Product or supplier actions, safety notices, refunds, and legal conclusions should require verification against the official notice and your own product records.

Pricing

Pricing is $0.01 per Actor start plus $0.003 per dataset result, displayed as $3.00 per 1,000 results. Apify platform usage is included rather than billed separately. Use limit and your Apify run-charge controls to keep recall monitoring within budget.

Legal and non-affiliation

FDA Device Recall Intelligence is an independent data-processing tool. FDA names, public data, and links belong to their respective owners. Use public sources according to their applicable terms and policies. You are responsible for validating data for your situation and for meeting the legal, device-safety, privacy, retention, and internal-control requirements that apply to your organization.

Related actors

Device recalls are one input to a product-safety picture. These siblings cover the neighbouring official sources and share the same output contract, so records join cleanly on firm name, date, and sourceUrl.

• Product Recall Intelligence: official CPSC consumer-product recalls. Use it when the item is sold at retail rather than regulated as a medical device, or when you need both views of the same firm.
• FDA Food Recall Intelligence: official openFDA food enforcement records for supplier risk and food-safety monitoring, built on the same enforcement-report shape.
• FDA Drug Safety Signals: FAERS adverse-event screening with PRR, ROR, and confidence intervals when the question moves from a recalled device to a drug safety signal.
• Vehicle Safety Intelligence: official NHTSA recalls, complaints, and safety ratings when a fleet or logistics workflow sits alongside the healthcare one.
• FDIC Bank Intelligence: official institution data with certificates, status, regulators, and source URLs for counterparty and vendor research.

Support and feedback

For a reproducible source-shape or output issue, open the actor's Issues tab with the input, sourceUrl, timestamp, actor run ID, and error text. Do not include confidential inventory, customer, or credential data. For a product request or a successful workflow, use the feedback section or leave a review. Specific examples of the expected recall field and the public source make feedback actionable.

Public proof artifact

The release evidence includes a rendered 1600 by 600 hero, a 1024 icon, three consecutive Apify Cloud runs, dataset IDs, row counts, record types, run costs, and a live Store screenshot. This evidence is retained with the factory receipt so buyers and operators can distinguish tested behavior from listing claims.

Why choose this Actor?

Generic recall feeds expose raw enforcement rows. FDA Device Recall Intelligence adds a stable schema, numeric completeness scores, ISO dates, normalized status and device class fields, per-record agentMarkdown, a run-level summary, top-firm counts, class counts, national-distribution signals, honest no-match behavior, and explicit source provenance. It fails on malformed or unexpectedly empty upstream payloads rather than presenting source failure as a reassuring zero.

Device-specific intelligence fields

Each recall row adds productCode, deviceName, deviceClass, medicalSpecialty, regulationNumber, deduplicated kNumbers, rootCause, action, firmFeiNumber, posted, initiated, and terminated dates, contact, and firm location. The summary groups recall status, device class, root cause, and medical specialty. This lets regulatory, quality, biomedical, procurement, and healthcare operations teams triage a recall feed without losing the FDA record that supports each decision.

Device recall review checklist

1. Match the device name, product code, model, lot, catalog number, and K number against local inventory.
2. Read reasonForRecall, rootCause, and action together. None is a substitute for the others.
3. Confirm recallStatus and the posted, initiated, and terminated dates at the official source.
4. Check the distribution pattern and firm contact before routing a local response.
5. Preserve the Actor run ID, recallNumber, sourceUrl, and retrievedAt in the review record.
6. Require an authorized quality or compliance owner to approve clinical, patient, inventory, supplier, or notification action.