# openFDA Recall Radar (`titan_coder/openfda-recall-radar`) Actor

Monitors FDA drug and medical device recalls (openFDA Enforcement API) for the firms and products you name, and reports only recall events genuinely new since your last check. A day with nothing new is free.

- **URL**: https://apify.com/titan\_coder/openfda-recall-radar.md
- **Developed by:** [Radu Furtuna](https://apify.com/titan_coder) (community)
- **Categories:** Business, News, Automation
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

$10.00 / 1,000 new recall detecteds

This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events.

Learn more: https://docs.apify.com/actors/running/actors-in-store.md#pay-per-event

## What's an Apify Actor?

Actors are web data automations that power AI and operations. They run on the Apify platform to scrape websites, process data, connect APIs, and automate workflows.
In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours,
and optionally produces a well-defined JSON output, datasets with results, or files in key-value store.
In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server.
Actors are written with capital "A".

## How to integrate an Actor?

If asked about integration, you help developers integrate Actors into their projects.
You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready.
The best way to integrate Actors is as follows.

- **AI agents and MCP clients** — the [Apify MCP server](https://docs.apify.com/integrations/mcp.md) at `https://mcp.apify.com` (remote, streamable HTTP, OAuth on first use).
- **Agentic workflows and local Actor development** — [Agent Skills](https://apify.com/.well-known/agent-skills/index.json) with the [Apify CLI](https://docs.apify.com/cli/docs.md): `npm install -g apify-cli`, then `apify login`.
- **JavaScript/TypeScript projects** — the official [JS/TS client](https://docs.apify.com/api/client/js/docs.md): `npm install apify-client`.
- **Python projects** — the official [Python client](https://docs.apify.com/api/client/python/docs.md): `pip install apify-client`.
- **Any other language** — the [REST API](https://docs.apify.com/api/v2.md).

For usage examples, see the [API](#api) section below.

For more details, see Apify documentation as [Markdown index](https://docs.apify.com/llms.txt) and [Markdown full-text](https://docs.apify.com/llms-full.txt).

# README

## 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_number`s 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

```json
{
  "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 `monitorId`s 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](https://www.fda.gov/safety/recalls-market-withdrawals-safety-alerts) 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)

# Actor input Schema

## `monitorId` (type: `string`):

Name of this monitor's durable history (a-z, 0-9, dash; up to 40 chars).

## `watches` (type: `array`):

1-30 objects: {"watchId": "pfizer-drugs", "productType": "drug", "field": "recalling\_firm", "value": "Pfizer Inc"}. productType is drug or device (openFDA has a separate enforcement database for each). field is recalling\_firm, product\_description, or classification (Class I/II/III) — exact phrase match against that openFDA field. New watches can be added later under the same monitorId.

## `notifyOn` (type: `string`):

new\_alerts — post the webhook only when new paid recalls were delivered; always — post it every run; never — do not call webhookUrl at all.

## `webhookUrl` (type: `string`):

Optional. Receives a digest of delivered (paid) new recalls as JSON. HTTPS only.

## Actor input object example

```json
{
  "monitorId": "example-monitor",
  "watches": [
    {
      "watchId": "pfizer-drugs",
      "productType": "drug",
      "field": "recalling_firm",
      "value": "Pfizer Inc"
    }
  ],
  "notifyOn": "new_alerts"
}
```

# Actor output Schema

## `results` (type: `string`):

Every row this run produced. Key fields: watchId, recallNumber, classification, recallingFirm, productDescription, reportDate, status. If nothing new was found, a single run\_summary row explains why the dataset is otherwise empty.

## `coverage` (type: `string`):

What this run actually covered and what it charged for: per-target status and reason, recalls delivered and recalls billed. Enough to reconcile every charge against every row.

## `digest` (type: `string`):

A short human-readable summary of what this run found, written every run.

# API

You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup.

## JavaScript example

```javascript
import { ApifyClient } from 'apify-client';

// Initialize the ApifyClient with your Apify API token
// Replace the '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {
    "monitorId": "example-monitor",
    "watches": [
        {
            "watchId": "pfizer-drugs",
            "productType": "drug",
            "field": "recalling_firm",
            "value": "Pfizer Inc"
        }
    ]
};

// Run the Actor and wait for it to finish
const run = await client.actor("titan_coder/openfda-recall-radar").call(input);

// Fetch and print Actor results from the run's dataset (if any)
console.log('Results from dataset');
console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => {
    console.dir(item);
});

// 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs

```

## Python example

```python
from apify_client import ApifyClient

# Initialize the ApifyClient with your Apify API token
# Replace '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = {
    "monitorId": "example-monitor",
    "watches": [{
            "watchId": "pfizer-drugs",
            "productType": "drug",
            "field": "recalling_firm",
            "value": "Pfizer Inc",
        }],
}

# Run the Actor and wait for it to finish
run = client.actor("titan_coder/openfda-recall-radar").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{
  "monitorId": "example-monitor",
  "watches": [
    {
      "watchId": "pfizer-drugs",
      "productType": "drug",
      "field": "recalling_firm",
      "value": "Pfizer Inc"
    }
  ]
}' |
apify call titan_coder/openfda-recall-radar --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,titan_coder/openfda-recall-radar"
        }
    }
}
```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/BT755demIaPBKRwac/builds/pME9NpryWRhCbQsSE/openapi.json