FDA Intel: Device Clearance Monitor
Pricing
from $5.00 / 1,000 510(k) or pma decision rows
FDA Intel: Device Clearance Monitor
Every new FDA 510(k), PMA, and De Novo clearance plus device recalls, enforcement actions, and establishment registrations for your product codes or companies, with weekly diff mode. Clean rows, summary links.
Pricing
from $5.00 / 1,000 510(k) or pma decision rows
Rating
0.0
(0)
Developer
Martyn Gross
Maintained by CommunityActor stats
0
Bookmarked
2
Total users
1
Monthly active users
23 days ago
Last modified
Categories
Share
Part of Iceni Data · FDA Intel
FDA Intel: Device Watchlist
Monitor FDA device clearances, recalls, and registrations by product code, applicant, or review panel — with a diff mode that returns only new clearances/recalls since a given date. Built on openFDA's /device/510k, /device/pma, /device/classification, /device/recall, /device/enforcement, and /device/registrationlisting endpoints, plus a weekly-refreshed cache of FDA's De Novo database (which has no official API). Runs on the Apify platform, so you get scheduling, an API, webhooks, and monitoring for free.
What does FDA Device Watchlist do?
This Actor is a single watchlist over three independent FDA data sources, selected with the record_types input:
- Clearance (
510k,pma,de_novo) — every 510(k) clearance, PMA approval/supplement, and De Novo classification grant for a product code, applicant, or review panel. This is the original Clearance Monitor behavior, unchanged. - Recall (
recall,enforcement) — device recalls from openFDA's/device/recalland the broader FDA compliance recall/enforcement reports from/device/enforcement, for the same product codes and applicant. - Registration (
registration) — FDA establishment registrations and device listings: who's registered to make or distribute a product code, and where.
Point it at a product code you care about (say QAS, radiological triage software) and it tells you every clearance FDA has issued for it, every recall against it, and every facility registered to make it — who, when, and where. Run it once for the full history, or schedule it daily/weekly with decision_after set to your last run date to get a diff of only new clearances/recalls since then — useful for competitive intelligence, regulatory tracking, or feeding a Slack/email alert.
Why use FDA Device Watchlist?
- Competitive intelligence: know the moment a competitor's device clears FDA, gets recalled, or a new facility registers to make it.
- Regulatory tracking: watch your own product codes for clearance, recall, and registration activity across the whole category, not just your own filings.
- Supply chain / diligence: pull every registered establishment and every recall for a product code before you partner with, acquire, or compete against a device maker.
- Market research: pull every decision, recall, or registration for a product code or panel to size a device category by volume, applicant, and pathway.
- No scraping of openFDA data — it's read straight from openFDA's stable, documented JSON APIs. Schedule it, hit it via the Apify API, or wire it into a webhook/integration.
How to use FDA Device Watchlist
- Click Try for free (or Start) on this Actor's page.
- In the Input tab, set
record_typesto whichever ofclearance,recall, andregistrationyou want (default:clearanceonly — you can select all three). - Set
product_codes,applicant_contains, and/or (for clearance)review_panelto whatever you want to track. Leave them blank to match everything (not recommended withoutdecision_after— see Pricing). - Optionally set
decision_afterto a date (YYYY-MM-DD) to only get clearance/recall rows since then — this is the diff mode, and what you'd use on a recurring schedule. Registrations have no decision date and are unaffected by it. - Click Start. When the run finishes, open the Dataset tab to view, filter, or export the results (JSON, CSV, Excel, HTML, and more) — or switch between the Clearances, Recalls, and Registrations views for a layout suited to each record type.
- To track De Novo decisions too (
include_de_novo: true, the default, only relevant whenrecord_typesincludesclearance), someone first needs to have run this Actor once withrefresh_de_novo: trueto build the cache — see De Novo data below. If the cache doesn't exist yet, De Novo rows are simply omitted; everything else still works.
Input
All fields are optional and every field has a description and example in the Input tab. Full schema: .actor/input_schema.json.
| Field | Type | Description |
|---|---|---|
record_types | array of strings | Which of "clearance", "recall", "registration" to fetch. Default ["clearance"]. |
product_codes | array of strings | FDA product codes to filter on, e.g. ["QAS", "OBO"]. Applies to every selected record type. Empty = match any. |
applicant_contains | string | Case-insensitive substring match on applicant/requester (clearance), recalling firm (recall), or owner/operator (registration) name, e.g. "Medtronic". Applies to every selected record type. |
review_panel | string | Two-letter advisory committee code ("CV") or full name ("Cardiovascular"). Clearance rows only. |
decision_after | string (date) | YYYY-MM-DD. Only clearance/recall rows on/after this date — the diff-mode knob. No effect on registration rows. |
include_de_novo | boolean | When record_types includes clearance, include cached De Novo grants alongside 510(k)/PMA. Default true. |
refresh_de_novo | boolean | Maintenance mode: refresh the De Novo cache and exit. No rows, no charges. Default false. |
Six worked inputs
1. Everything FDA has cleared for a specific product code:
{"record_types": ["clearance"],"product_codes": ["QAS"],"include_de_novo": true}
2. Diff mode — new decisions across two product codes since a date, for a scheduled daily/weekly run:
{"record_types": ["clearance"],"product_codes": ["QAS", "OBO"],"decision_after": "2026-08-01","include_de_novo": true}
3. Everything a specific applicant has gotten cleared in a review panel, all history:
{"record_types": ["clearance"],"applicant_contains": "Medtronic","review_panel": "CV","include_de_novo": false}
4. Recall watchlist — every device recall and enforcement report for a product code since a date:
{"record_types": ["recall"],"product_codes": ["LWS"],"decision_after": "2026-01-01"}
5. Registration watchlist — every facility registered to make a product code:
{"record_types": ["registration"],"product_codes": ["QAS"]}
6. Full watchlist on one applicant — clearances, recalls, and registrations together:
{"record_types": ["clearance", "recall", "registration"],"applicant_contains": "iSchemaView"}
Maintenance run (typically on its own weekly schedule, with no other filters):
{"refresh_de_novo": true}
Output
One flat JSON object per clearance, recall/enforcement report, or registered product listing, pushed to the default dataset. You can download it as JSON, CSV, Excel, HTML, XML, or RSS from the Export results button. Dates are ISO 8601 (YYYY-MM-DD); missing values are null, never empty strings; fields that don't apply to a row's decision_type are simply null.
What each record type returns
- Clearance (
decision_type:510k/pma/de_novo) — the decision number, device/trade name, applicant, product code, device class, regulation number, review panel, decision date/code, and a link to the public summary document. - Recall (
decision_type:recall/enforcement) — the FDA recall number, device/product description, recalling firm, product code, recall classification (Class I/II/III — only reported by/device/enforcement), reason for recall, root cause (only reported by/device/recall), status, event initiation date, report date, and any 510(k) numbers openFDA has linked to the recalled product. - Registration (
decision_type:registration) — the FDA registration number, proprietary (device trade) name, owner/operator firm, product code, and the registered establishment's type, city, state, and country.
What it does not return
- No PDF text extraction or parsing of any kind —
summary_urlis a link, not content. - No MedWatch adverse-event narratives (MAUDE) — this Actor covers clearances, recalls/enforcement, and registrations only, not adverse event reports.
- No UDI/GUDID data (device identifiers, packaging, or catalog numbers) — that's a separate FDA database. AccessGUDID has its own free public API if you need it.
- No enrichment from third-party sources (company financials, news, LinkedIn, etc.) — every field comes directly from FDA/openFDA.
- No personal data — these are corporate regulatory filings, not individuals.
- PMA rows have no
applicant_country— openFDA's/device/pmaendpoint doesn't expose one. Recall/enforcement'sproduct_codeis populated inconsistently by FDA —/device/recallcovers it reliably,/device/enforcementoften leaves it blank.
Example output rows
Clearance:
{"decision_type": "510k","number": "K261085","device_name": "Rapid Vessel Occlusion (Rapid VO)","applicant": "iSchemaView","product_code": "QAS","device_class": "2","regulation_number": "892.2080","review_panel": "Radiology","decision_date": "2026-07-13","decision_code": "SESE","summary_url": "https://www.accessdata.fda.gov/cdrh_docs/pdf26/K261085.pdf","applicant_city": "Golden","applicant_state": "CO","applicant_country": "US","classification": null,"reason_for_recall": null,"root_cause": null,"status": null,"event_initiation_date": null,"openfda_k_numbers": [],"establishment_type": null,"establishment_city": null,"establishment_state": null,"establishment_country": null,"data_as_of": "2026-09-04","source_urls": ["https://api.fda.gov/device/510k.json?search=k_number:\"K261085\"","https://api.fda.gov/device/classification.json?search=product_code:\"QAS\""]}
Recall:
{"decision_type": "recall","number": "Z-0001-04","device_name": "Sedecal SP-HF 4.0 Portable X-Ray System","applicant": "Sedecal USA, Inc","product_code": "IZL","device_class": null,"regulation_number": null,"review_panel": null,"decision_date": "2003-10-29","decision_code": null,"summary_url": null,"applicant_city": null,"applicant_state": null,"applicant_country": null,"classification": null,"reason_for_recall": "A minimum source-skin-distance of less than 30 cm and not identifying the tube manufacturer on the tube housing label resulted in the SP-HF-4.0 Portable Systems not complying with the U.S. Federal performance standard.","root_cause": "Other","status": "Terminated","event_initiation_date": "2003-10-27","openfda_k_numbers": ["K020436"],"establishment_type": null,"establishment_city": null,"establishment_state": null,"establishment_country": null,"data_as_of": "2026-09-04","source_urls": ["https://api.fda.gov/device/recall.json?search=product_res_number:\"Z-0001-04\""]}
Registration:
{"decision_type": "registration","number": "3011205675","device_name": "Rapid ICH","applicant": "iSchemaView, Inc.","product_code": "QAS","device_class": null,"regulation_number": null,"review_panel": null,"decision_date": null,"decision_code": null,"summary_url": null,"applicant_city": null,"applicant_state": null,"applicant_country": null,"classification": null,"reason_for_recall": null,"root_cause": null,"status": null,"event_initiation_date": null,"openfda_k_numbers": [],"establishment_type": "Manufacture Medical Device","establishment_city": "Golden","establishment_state": "CO","establishment_country": "US","data_as_of": "2026-09-04","source_urls": ["https://api.fda.gov/device/registrationlisting.json?search=registration.registration_number:\"3011205675\""]}
Data table
| Field | Description |
|---|---|
decision_type | "510k", "pma", "de_novo", "recall", "enforcement", or "registration". |
number | The row's identifying number: K123456/P123456 (or P123456/S001)/DEN123456 for clearances, an FDA recall number (e.g. Z-1234-24) for recall/enforcement, or an FDA registration number for registrations. |
device_name | Device/trade name (clearances), device or product description (recall/enforcement), or proprietary name (registrations). |
applicant | Applicant/requester company (clearances), recalling firm (recall/enforcement), or owner/operator firm (registrations). |
product_code | FDA 3-letter product code. |
device_class | Clearance only. 1, 2, or 3, from the classification join. |
regulation_number | Clearance only. 21 CFR regulation number, from the classification join. |
review_panel | Clearance only. FDA medical specialty / advisory committee panel name. |
decision_date | Date FDA issued the decision (clearance) or the report date (recall/enforcement). null for registrations. |
decision_code | Clearance only. FDA's short decision code (e.g. SESE, APPR, DENG). |
summary_url | Clearance only. Link to the decision's public summary — a PDF for 510(k)/De Novo, FDA's database page for PMA. Not parsed. |
applicant_city / applicant_state / applicant_country | Clearance only. Applicant's filed address, where the source provides it. |
classification | Recall/enforcement only. FDA recall class I, II, or III. Only /device/enforcement reports this — always null on recall rows. |
reason_for_recall | Recall/enforcement only. FDA's stated reason for the recall. |
root_cause | Recall only. Firm-reported root cause. Always null on enforcement rows. |
status | Recall/enforcement only. Recall status, e.g. Ongoing, Terminated, Open, Classified. |
event_initiation_date | Recall/enforcement only. Date the firm initiated the recall. |
openfda_k_numbers | Recall/enforcement only. 510(k) number(s) openFDA has linked to the recalled product. Often empty. |
establishment_type / establishment_city / establishment_state / establishment_country | Registration only. The registered establishment's operation type and address. |
data_as_of | Snapshot date this row's data reflects. |
source_urls | The exact API/page URL(s) this row was built from. |
De Novo data
FDA has no official API and no bulk-download file for De Novo classification grants (openFDA doesn't cover it at all — verified against its own endpoint manifest). The only source is FDA's HTML search interface at accessdata.fda.gov, which is bot-protected. Because of that, De Novo works differently from 510(k)/PMA:
- A separate maintenance run with
refresh_de_novo: truescrapes FDA's De Novo database (through a ScraperAPI-style proxy — set theSCRAPER_API_KEYenvironment variable) and stores a snapshot in the Actor's key-value store. This run returns no rows and charges nothing. Schedule this weekly. - Normal monitoring runs with
record_typesincludingclearanceandinclude_de_novo: trueread that cached snapshot and filter it the same way as 510(k)/PMA results — they never hit FDA's site directly. - If nobody has run a refresh yet, De Novo rows are simply omitted (a log warning explains why); 510(k)/PMA results are unaffected.
- De Novo rows are charged via the
de_novo_returnedevent only when the cache is 14 days old or less. Older ("stale") cached rows are still returned — useful if a refresh has been failing — but aren't charged, anddata_as_ofreflects the cache's actual snapshot date, not today. - The refresh is incremental (only fetches DEN numbers not already cached, newest first, capped per run) and self-heals a full backfill over a few weekly runs rather than one long one.
Refresh cadence by source
| Source | Refresh cadence |
|---|---|
/device/510k, /device/pma | Live on every run — openFDA is a stable, documented JSON API. |
/device/classification | Live on every run, joined by product_code. |
/device/recall, /device/enforcement | Live on every run. |
/device/registrationlisting | Live on every run. |
| De Novo | Weekly, via a dedicated refresh_de_novo: true run. Never fetched live from a monitoring run. |
Pricing / Cost estimation
This Actor uses the pay-per-event pricing model — you pay per row returned, not per compute second:
record_returned— charged once per clearance (510(k)/PMA) row or registration row ($0.005/row).de_novo_returned— charged once per De Novo row, only when served from a fresh (≤14-day-old) cache.recall_returned— charged once per recall/enforcement row.
(Event prices are configured in Apify Console under this Actor's monetization settings, not in code.)
Free-plan users are capped at 25 rows per run, combined across every selected record_type. Once that's hit, the Actor stops, sets the status message to Free tier limit reached, and exits normally (not an error) — no partial charges, no crash. Narrow your filters (product_codes, applicant_contains, review_panel, decision_after) to stay under that on the free plan, or upgrade for unlimited rows.
An unfiltered run (no product_codes, no applicant_contains, no review_panel, no decision_after) queries FDA's entire history for whichever record_types you selected — expect a lot of rows and, on the free plan, hitting the cap almost immediately. Always set at least one filter.
Tips / Advanced options
- Combine
product_codesanddecision_afterfor the tightest, cheapest diff-mode queries. review_panelaccepts either the 2-letter advisory committee code or the descriptive name — both work, e.g."CV"and"Cardiovascular"are equivalent.- Run the
refresh_de_novo: truemaintenance task on a separate weekly schedule from your monitoring runs. - Select multiple
record_typesin one run to build a single company or product-code dossier — clearances, recalls, and registered manufacturing sites together — instead of running three separate Actors. source_urlson every row is a deterministic, single-record openFDA (or FDA page) URL — reusable outside the Actor to spot-check any row.
FAQ, disclaimers, and support
- Is this legal? Yes — 510(k)/PMA/De Novo decisions, recalls, enforcement reports, and establishment registrations are all public FDA regulatory records. The live-queried data comes from openFDA's public API, per its terms of use. The De Novo cache-refresh step respects
robots.txtand skips itself if disallowed. - This isn't medical or regulatory advice. Per openFDA's own disclaimer, don't rely on this data (or on openFDA) to make decisions regarding medical care; treat all results as unvalidated and verify anything decision-critical directly against FDA's own systems.
- Known limitations: PMA rows have no applicant country (not in the source data). The constructed 510(k)/De Novo PDF
summary_urlfollows FDA's standard document-path convention but isn't returned directly by openFDA, so it can occasionally 404 for older or corrected submissions./device/enforcement'sproduct_codefield is populated for only a minority of records — recall coverage by product code is stronger via/device/recall. De Novo data depends on a separately-maintained weekly cache and a workingSCRAPER_API_KEY. - Found a bug or have a feature request? Use this Actor's Issues tab. Need a custom variant (different sources, extra filters, alerting)? Reach out via the same tab.
Related tools
Part of the FDA Intel family on Apify:
- FDA Intel: Device Watchlist (this Actor) — clearances, recalls & enforcement, and registrations & listings.
- Adverse Events (MAUDE) — coming soon.
- Adverse Event Summaries — MAUDE adverse event report summaries by device or manufacturer.