openFDA Recall Radar

Durable monitor for FDA drug and medical device recalls — via the official, free openFDA Enforcement API. No API key needed.

Why

Compliance teams, pharmacies, distributors, hospitals and device resellers need to know the moment a tracked manufacturer or product shows up in an FDA recall (Class I recalls can trigger mandatory customer notification and product-pull deadlines). Existing openFDA tools on Apify are one-off scrapers/dumps — pull everything and pay per row every time, with no notion of "what's new since last week". This actor is a durable watch: it remembers what it has already reported and charges only for genuinely new recall events.

How it works

1. Each watch targets one openFDA Enforcement endpoint — drug or device — filtered by an exact match on one field: recalling_firm (a company name), product_description (a product/brand name), or classification (Class I/Class II/Class III — broad, use with care).
2. Every run fetches that watch's most recent recall records (sorted newest-first by report_date) and diffs them against a durable checkpoint of recall_numbers already seen for that watch.
3. Genuinely new recalls are pushed to the dataset and billed once each (new-recall-detected); checking a watch with nothing new costs nothing beyond the fixed platform run cost.

Input

{
  "monitorId": "example-monitor",
  "watches": [
    { "watchId": "pfizer-drugs", "productType": "drug", "field": "recalling_firm", "value": "Pfizer Inc" },
    { "watchId": "acme-pumps", "productType": "device", "field": "recalling_firm", "value": "Acme Medical" }
  ],
  "notifyOn": "new_alerts",
  "webhookUrl": "https://example.com/webhook"
}

Add more watches later under the same monitorId — each watch keeps its own independent history.

Billing

Pay-per-event: new-recall-detected — charged only for a recall record genuinely new since the previous check of that watch. The first check of a new watch establishes a baseline (no charge). Failed/blocked checks are never charged.

Delivery guarantee: at-most-once (not exactly-once)

The right to write a row and to charge for it is granted by a single atomic primitive — one addRequest(uniqueKey) into a dedicated, named claim-journal Request Queue (<prefix>-<monitorId>-claims). Exactly one run ever wins that key. Claim requests are never deleted and never handled: the queue is a permanent journal of irreversible attempts, not a work list.

What this buys you, stated honestly:

• You will never be charged twice for the same event. That is the guarantee.
• It is not exactly-once. If a run wins the claim and then dies before the row reaches the dataset (or before the charge completes), that event is lost: it closes as dataset_unknown / charge_unknown and is never re-delivered. We deliberately prefer losing a delivery over double-charging you.
• Boundary of the guarantee: it holds for as long as the named claim-journal queue exists. Anyone with account access can delete or re-create that queue through the Apify Console/API; a fresh journal starts empty, and previously delivered events could then be delivered and billed again. That is an inherent limit of any durable storage, not a defect of the protocol.
• Migration boundary: the guarantee applies from the build that introduced the claim gate onward. Older builds of this actor must not keep running against the same monitorId — they predate the journal and would not see the claims it holds.
• coverage.claimJournalSize reports the journal's size each run (best-effort; null if the queue's metadata could not be read, and the value lags by a few seconds because Apify's totalRequestCount is eventually consistent). Use it to watch growth, not to make decisions.

One-time storage rename in the claim-gate build

Named storages used to be derived from the full actor name (openfda-recall-radar, 20 characters). With a 40-character monitorId the lease queue name reached 67 characters — over Apify's 63-character limit, so long monitorIds could not work. They are now derived from a short prefix (openfda-rr), which keeps every name — including the new -claims queue — inside the limit. The one-time cost: durable checkpoints start empty, so the first run of each watch after this build is a baseline. A baseline delivers no rows and charges nothing, so this cannot cause double billing; you only lose one delta window.

Honest limits

• Each check fetches the 100 most recent recall records matching the watch — sufficient for monitoring, since new recalls appear at the top (sorted by report_date descending). coverage.windowFullCount flags when a watch has more matching records than fit in that page since the last check (informational, not an error).
• seenIds per watch is capped (FIFO by discovery order); an evicted, then re-surfaced recall_number can be re-billed — only matters for extremely high-volume watches.
• This monitor bills once per newly-discovered recall_number. A later status change on an already-billed recall (e.g. Ongoing → Terminated) is visible if you re-run a broad enough watch, but it is not re-billed or flagged as a separate "update" event — durably tracking every field mutation on an already- seen recall is out of scope for v1.
• We don't invent data: if the openFDA response shape changes, or a watch's field/value combination is invalid, the run reports it honestly instead of silently returning zero results. openFDA's own documented "no matches" response (HTTP 404 with error.code = NOT_FOUND) is treated as a valid empty result, not a failure.
• openFDA does not provide a direct public URL per recall record. Use recallNumber to look the record up on fda.gov or via the API directly.
• openFDA data itself carries FDA's own disclaimer: "unvalidated" — do not use this feed alone for medical decisions.

Author: OmniCoder (https://t.me/OmniCoder)