CPSC Recall-to-Catalog Matcher — Manufacturer, Model, UPC

Compare a nonsecret product catalog with official U.S. Consumer Product Safety Commission (CPSC) recalls in an explicit date window. Receive published recall links, dates, manufacturers, product labels, model and UPC evidence, conservative confidence labels, and exact changes from a caller-supplied earlier snapshot.

Every candidate requires human review. A nonmatch does not mean a product is safe. This Actor does not issue safety, legal, medical or regulatory decisions, and does not determine whether a recall is resolved or withdrawn.

What it supports

• One fixed public source: https://www.saferproducts.gov/RestWebServices/Recall, linked by the official CPSC API page.
• Documented format=json, RecallDateStart, and RecallDateEnd query parameters. The official programmer's guide documents no pagination cursor or reliable total-count contract. This Actor never invents page parameters.
• Date partitions overlap at their endpoints; one extra end boundary is fetched, then records are filtered to the inclusive requested calendar days. Identical recalls are deduplicated by RecallID. Conflicting copies fail the scan rather than silently overwriting evidence.
• Exact normalized UPC matches preserve leading zeros and identifier length. Only spaces and hyphens are removed. UPC/EAN/GTIN lengths of 8, 12, 13 and 14 are accepted; different padded lengths are not conflated and check digits are not certified.
• Exact whole structured model fields retain punctuation. When structured models are missing, a whole literal model token in published product names/descriptions or recall description becomes lower-confidence evidence. No model ranges, tables, aliases, inferred brands or semantic matches are invented.
• Manufacturer matching is whole-string, case-insensitive, whitespace-normalized equality. Manufacturer locations and legal suffixes are retained; callers should use the exact published organization label when appropriate.

The source frequently leaves structured model/UPC fields empty. October 2026 live samples demonstrated this. Importer, distributor, brand, and manufacturer are distinct roles; an importer is never substituted for a missing manufacturer.

Input

See examples/input.json. Required fields are recallDateStart, recallDateEnd (YYYY-MM-DD) and catalog. Each catalog item has a unique productId, optional manufacturer, and at least one identifier in models or upcs. Both identifier lists contain strings. Do not supply customer, health, contact, login or other sensitive information. Extra catalog fields are rejected.

{
  "recallDateStart": "2026-10-01",
  "recallDateEnd": "2026-10-02",
  "catalog": [{"productId": "my-widget", "manufacturer": "Example Co.", "models": ["AB-12"], "upcs": ["001234567890"]}],
  "maxResults": 1,
  "maxBudgetUsd": 0.02
}

This illustrative catalog is fictional. The complete example file uses a published October 2026 recall model solely to demonstrate a live candidate; it does not represent an actual customer inventory.

Output and interpretation

The dataset contains one completed catalog-product evaluation per input product, including products for which no candidate was found among the scanned recalls. Each row contains key, evidence.catalogProduct, evidence.matchStatus, evidence.candidates, completeScan, scopeKey, observedAt, humanReviewRequired: true, safetyConclusion: null and change.

Candidates include the exact selected source fields, source recall URL, model/UPC/manufacturer evidence, confidence (high, medium, low), and ambiguity reasons. Confidence is a deterministic evidence tier, not a probability or recall applicability verdict. Exact UPC or structured model plus exact manufacturer can be high confidence, but conflicting manufacturers, reused identifiers or recall-level UPC ambiguity reduce it. Multiple products/manufacturers prevent assuming a particular manufacturer belongs to a particular product. Multiple recall candidates remain visible.

OUTPUT in the default key-value store contains:

• diagnostics: requested catalog/date scope, request URLs, timestamps, raw-response SHA256 hashes, response sizes, retries, partition coverage, byte/request/result budgets, record counts and stop reasons.
• diagnostics.queryComplete: every requested API partition was processed without a detected failure or source cap.
• diagnostics.completeScan: query processing and every catalog evaluation finished within all bounds. This is bounded query completion, not a guarantee the upstream service returned every recall. globalRecallCoverage always remains unverified because the API publishes no total/exhaustiveness contract.
• comparison: exact normalized before/after evidence only when the current scan is complete and previousSnapshot has the same catalog and dates. Observed-at times and response hashes do not create false changes.
• previousSnapshot: reusable only for a complete scan. Paste this object into a subsequent input for the exact same catalog and date window. No global or cross-user state is used. Caller-supplied snapshots are structurally validated, but their historical source authenticity cannot be guaranteed.
• partialObservations: bounded diagnostic evidence on incomplete scans. No dataset rows are emitted or custom result events charged for an incomplete scan, and its snapshot is null.

Source disappearance or a lost candidate is never reported as recall withdrawal, successful remedy or product safety. Date scope uses original RecallDate; amendments to older recalls outside the window are not monitored. Run a separate wider date window to review older recalls. Changing the date window or catalog intentionally creates a different snapshot scope.

Bounds

Input	Default	Hard maximum
Catalog products	required	250
Models / UPCs per product	0 / 0	10 each
Date span	explicit	366 calendar days
Partition days	7	31
Unique recalls	500	1,000
Catalog result rows	100	250
Candidates per product	25	25
HTTP attempts, including retries	30	100
Retries per partition request	2	3
Scan seconds	90	300
Single response bytes	3 MB	10 MB
Aggregate response bytes	12 MB	20 MB
Input / reusable snapshot bytes	1.5 MB / 1 MB	fixed
Event budget USD	0.25	20

A bounded scan that reaches a cap is incomplete. Increase relevant limits within the hard maxima or narrow the date window. Retry-After is respected when it fits within remaining scan time; longer waits stop the run. Access denials and redirects stop the scan without bypass. Only fixed official API URLs are fetched. Recall links in results are evidence references and are never crawled. No proxies, paid services, login or personal-contact harvesting are used.

Local use

Requires Node.js 22 or newer.

npm ci --ignore-scripts
npm test
npm run validate:schema
npm run smoke

smoke performs a small public read-only live request and writes artifacts/live-smoke.json and example output. To run the actual SDK entrypoint locally, place an example input at storage/key_value_stores/default/INPUT.json, then run npm start. Apify account credentials are unnecessary for local execution. Do not commit local storage or credentials.

Pricing and billing

Approved listing price: $0.002 per completed catalog-product evaluation (one catalog-product event per emitted dataset row), plus $0.005 automatic Actor start per memory unit up to 1 GB. The approved custom start rate differs from Apify's published default; it must be deliberately configured by the owner. This source does not configure account prices and never manually charges apify-actor-start. Default memory is 256 MB; a start reserves at least one unit.

The evaluation charge includes a transparent no-candidate observation because the bounded recall window was actually checked; it is never sold as a safety clearance. Candidate count does not multiply the charge. Incomplete scans deliver diagnostic partial evidence without custom result charges. The price reflects a bounded API fetch plus per-product identifier evaluation, not a measured market price or guaranteed profitability.

On a paid platform run, actual event prices and prior charges come from the SDK. Positive apify-default-dataset-item pricing is rejected to prevent double billing. The configured platform event cap is checked before work and each push. maxBudgetUsd limits event estimates/charges, not platform compute, storage or network fees. Automatic start can occur before Actor code and cannot be prevented by setting an input budget to zero. Concurrent platform cap changes can interrupt delivery; then comparison/snapshot are suppressed. See PUBLISHING.md.

Verification

See QA.md for fixture tests, official schema validation, live source evidence, production audit and local SDK memory evidence. Cloud build and controlled Apify runs were verified on 2026-10-11 at 256 MB. Baseline and same-scope unchanged runs each delivered two rows with complete scans. A $0.005 platform event cap made no source requests and emitted no rows; an exact $0.007 cap delivered one no-candidate evaluation. The platform recorded one automatic start plus the expected custom events, with no paid default-dataset event. Owner testing incurred platform usage rather than customer event invoices; customer payment settlement and every maximum-size workload remain unverified. Original QA.md records local build-stage evidence; these cloud checks extend that dated record. No recall coverage or safety guarantee is implied.