Build FDA Recall Compliance Alerts

A production feed needs more than a scheduled scrape. The FDA Recalls Scraper handles collection from the official openFDA food, drug, and device enforcement APIs; the rest of the pipeline should make ownership and state explicit.

Recommended data flow

Saved Apify Task -> raw dataset -> keyed upsert -> qualification -> owner queue -> alert

Store the composite key product_type:recall_number. Route ongoing Class I events immediately, send Class II events to the relevant quality owner, and close alerts only after a termination date or documented review.

Keep raw and derived data separate. The raw table should mirror source fields and collection metadata. The derived table can add scores, owners, workflow status, and internal notes. When a scoring rule changes, rebuild the derived table rather than editing source history.

Failure handling

Promote a snapshot only when the Actor run succeeds and passes basic checks: nonzero rows when rows are expected, valid keys, parseable dates, and no unexpected schema loss. Retry network failures with a bounded policy. Do not create downstream deletion events from a failed collection.

Enforcement records change during an investigation. Refresh ongoing recalls and retain code_info and distribution_pattern. A company-name match alone is not enough to decide whether inventory is affected.

Track three operational metrics: successful run rate, time from source publication to owner delivery, and the percentage of alerts that owners accept. Those numbers expose different failures. Availability problems hurt the first, an infrequent schedule hurts the second, and weak qualification hurts the third.

Start with one destination and one owner group. Add CRM, warehouse, or webhook branches after the keyed dataset and alert rules have stayed stable through several runs.