openFDA Approvals Monitor avatar

openFDA Approvals Monitor

Pricing

from $10.00 / 1,000 approval returneds

Go to Apify Store
openFDA Approvals Monitor

openFDA Approvals Monitor

Change-detection over the FDA approval and clearance stream: new drug approvals (Drugs@FDA), device 510(k) clearances and PMA approvals, unified into one normalized approval record (regulator, applicant, product, date, pathway). Filter by applicant, endpoint or date. Keyless, CC0.

Pricing

from $10.00 / 1,000 approval returneds

Rating

0.0

(0)

Developer

ByteHaven Studios

ByteHaven Studios

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

1

Monthly active users

2 days ago

Last modified

Share

First-seen change-detection over the FDA approval/clearance stream. One run watches three regulatory silos at once — new drug approvals (Drugs@FDA), device 510(k) clearances, and device PMA approvals — and folds their heterogeneous schemas into ONE normalized approval record (regulator, applicant, product, approval date, pathway = NDA/ANDA/BLA/510k/PMA). Filter by applicant (competitor watch), device product code, endpoint, or date window; a new-since-last-run mode keeps a per-endpoint high-water-mark and emits each newly-appeared approval once.

Clean REST/JSON — no browser, no proxy, no login, no API key required. Data source: openFDA (FDA), U.S. public domain, CC0 1.0 Universal.

This product uses data from the U.S. FDA openFDA API (public domain, CC0 1.0). It is not endorsed or certified by the FDA and is not a substitute for the official FDA approval/clearance records.

Status: launch-ready (v0.1), unpublished. The runtime (src/openfda.js, src/filters.js, src/main.js) and its offline test suite are complete; the Actor is not published to the Apify Store and no on-platform price is set (see docs/PRICING.md). See CHANGELOG.md for detail.


What it does

For each run it queries the selected openFDA approval endpoints over a date window (api.fda.gov/drug/drugsfda.json, /device/510k.json, /device/pma.json), normalizes every raw record into one flat approval shape, dedupes on the endpoint-appropriate key, keeps only approvals dated after the last-run per-endpoint high-water-mark, and pushes one dataset item per approval.

  • Cross-silo normalization (the moat): content farms scrape drug labels and adverse-events in bulk; nobody unifies the first-seen approval/clearance stream across the drug and device silos into one comparable record. This does exactly that — "what got approved this week", filterable.
  • Applicant / product-code filter: watch a competitor's approvals, or a device product code.
  • Pathway classification: each record carries pathway (NDA / ANDA / BLA / 510k / PMA).
  • New-approval monitor: monitorNewOnly persists the max approval date per endpoint (in the Actor's key-value store) and, on the next scheduled run, emits only approvals dated after it.

Inputs

InputTypeNotes
endpointsstring[]Which streams: drug, 510k, pma. Empty = all three (cross-silo moat)
applicantsstring[]Optional applicant/sponsor substrings (competitor watch). Empty = all
productCodesstring[]Optional device product codes (510k/PMA only). Empty = all
approvedSincestringApproval-date lower bound (YYYY-MM-DD). Empty = recent trailing window
approvedUntilstringOptional approval-date upper bound (YYYY-MM-DD). Empty = up to today
monitorNewOnlybooleanEmit only approvals after the stored per-endpoint high-water-mark
fieldsstring[]Optional override of kept fields (see default set below). Empty = default
maxResultsintegerCap total approvals returned across endpoints (0 = no cap)
apiKeystringOptional free openFDA api_key (raises daily rate limit; not required)
proxyConfigurationobjectOptional; the API is open and needs no proxy. Default: none

Output — one record per approval (intended shape)

{
"approvalId": "K033177",
"endpoint": "510k",
"regulator": "FDA",
"center": "CDRH",
"pathway": "510k",
"applicant": "Acme Medical Inc.",
"productName": "Acme Glucose Meter",
"productCode": "NBW",
"applicationNumber": null,
"activeIngredients": null,
"advisoryCommittee": "CH",
"decisionCode": "SESE",
"decisionDescription": "Substantially Equivalent",
"approvalDate": "2026-07-08",
"isNew": true,
"attribution": "This product uses data from the U.S. FDA openFDA API (public domain, CC0 1.0). It is not endorsed or certified by the FDA and is not a substitute for the official FDA approval/clearance records.",
"fetchedAt": "2026-07-10T14:00:00.000Z"
}

approvalId is the endpoint-appropriate dedupe key — k_number (510k), pma_number+supplement_number (PMA), or application_number+submission (drug). Drug records instead carry applicationNumber + activeIngredients + productName (brand name) with pathway NDA/ANDA/BLA; device records carry productCode + decisionCode. Absent fields are null. isNew is true when an approval was not seen in a previous run (only meaningful with monitorNewOnly). Every record carries the courtesy attribution disclaimer.

Control records (not charged)

Two non-approval records may be pushed to signal run state. Neither triggers an approval-returned charge:

RecordWhenShape
_noDataNo approvals matched the endpoint/filter/window{ "_noData": true, "filters": {...}, "message": "...", "fetchedAt": "..." }
_errorThe fetch failed after retries, or normalization threw{ "_error": true, "filters": {...}, "message": "...", "fetchedAt": "..." }

_noData keeps a zero-result run green and auditable rather than pushing a silent empty dataset.

Pricing (pay-per-event)

One approval-returned event is charged per approval record pushed to the dataset. Cost scales with results, not runtime. Use endpoints / applicants / productCodes / maxResults / monitorNewOnly to keep spend proportional to signal. (Live price shown on the Store page; the pricing model + reasoning are in ./docs/PRICING.md.)

Data source & attribution

openFDA content and data are public domain under a Creative Commons CC0 1.0 Universal dedication — free to copy, modify and redistribute, including commercially, without asking permission. No key and no attribution are required; we credit the FDA / openFDA as a courtesy and surface a no-endorsement disclaimer on every record. Full compliance record: ./COMPLIANCE.md.

openFDA is a research/informational service; approval data may be incomplete or lag the FDA's own systems and is not a substitute for the official Drugs@FDA / 510(k) / PMA databases. This Actor relays the data as published; it does not certify accuracy.

Maintenance notes

  • Three schemas, two date semantics. Drug records are a nested submissions[] array with a compact YYYYMMDD submission_status_date; a "new approval" is the first AP submission. Device records (510k/PMA) are flat with an ISO decision_date. The normalizer folds all three into one approval shape defensively (optional chaining, not fixed indexes).
  • Dedupe keys differ. 510(k) = k_number (globally unique); PMA = pma_number + supplement_number; drug = application_number + submission_type + submission_number. The normalizer builds the endpoint-appropriate approvalId.
  • Query-based, not a firehose. openFDA has no "approvals since date X" endpoint — the delta is emulated per endpoint by a date-range search from the stored watermark, paged newest-first.
  • Paging ceilingslimit ≤ 1000, skip ≤ 25,000; wide windows must switch to search_after or split the date range. openFDA answers a zero-match query with HTTP 404 (not an empty list) — treat as "no data", not an error.
  • Weekly last_updated cadence — approvals post in weekly batches, so a monitoring schedule should overlap its date window run-to-run to avoid missing a late-posted approval.
  • Rate limits — keyless is 240 req/min and 1000/day per IP; an optional free apiKey raises the daily cap to 120,000. Large historical pulls should throttle and back off on 429.
  • Courtesy User-Agent — not mandated, but sent on every request (USER_AGENT const).