Building a Product Recall Data Notification Service: From Notice Scraping to Affected Batch Matching

Product recall data is already public, so why do consumers and merchants still miss recalls that apply to them? Because a notice answers "what happened," while a notification service must answer "does this notice correspond to the item in my hands, and what should be done now?" Between the two lie item identification, batch matching, evidence grading, continuous revision, and reliable delivery.

A recall reminder product introduction on r/newproducts proposes using photos to save purchased items and notify users when relevant recalls appear. This post only illustrates a hypothesis-stage user task; it does not prove recognition accuracy, immediacy, or willingness to pay. What is truly worth studying is how "the items I own" can be reliably connected to recall scopes published by regulatory agencies.

The Challenge Is Not Scraping Notices, But Determining Hits

Recall titles usually contain brands, categories, or product series, but the conditions that truly determine whether an item is affected may be hidden in model numbers, production dates, batches, serial numbers, UPCs, package sizes, sales regions, and sales timeframes. Doing full-text matching solely on product names pushes similar but unaffected items to users, while overly strict conditions may omit records with incomplete fields.

CPSC's recall API provides machine-readable JSON or XML access to public recall information, supporting queries by title, description, and product name. This provides an entry point for stable collection, but a queryable API does not mean every record contains unified item identifiers. The product must allow "missing fields" and "manual confirmation required" to be normal states.

Version one should not promise that photos will automatically determine everything. A more viable promise is to save identifiers the user can provide, run matching when new notices appear or old ones are revised, immediately alert users on high-confidence hits, ask users to check models or batches on suspected hits, and clearly state what is missing when judgment is impossible.

Do Not Flatten Different Regulatory Sources Into One Universal Field Table

Recall records for consumer goods, food, drugs, vehicles, and different countries or regions come from different sources and legal contexts. openFDA's food API endpoint separates datasets such as enforcement, while the food enforcement report query example demonstrates date ranges and category filtering. They support food enforcement report searches, but they should not be rewritten into a unified real-time API for all product recalls.

The internal data layer can use a common shell while preserving original source appearances. Common fields are used for retrieval and delivery, while source fields are used for verification:

• Unified identifier, source agency, source record ID, notice date, and last check time.
• Product name, brand, model number, code, batch, sales region, and sales timeframe; missing values must remain empty.
• Risk description, remedy method, consumer contact channels, and original notice link.
• Current status, previous version, field changes, and collection failure status.
• Original records or traceable snapshots to prevent the standardization process from erasing key qualifiers.

A common shell does not force different sources to have the same precision. If a record only has a natural language description, it should remain labeled as natural language; a non-existent SKU should not be inferred just to keep the database neat.

Matching Results Must Be Categorized Into Confirmed, Suspected, and No Evidence

A recall notification system requires an explainable matching ladder. The strongest evidence is usually a precise identifier combination, such as UPC and batch matching simultaneously, or model number and serial number range matching simultaneously. Next might be model and sales timeframe matching, but missing the batch. Only when a brand is similar to a fuzzy name should it be a pending clue rather than "your product has been recalled."

Matching output can be designed in three categories:

1. Confirmed hit: Key identifiers in the record match user registration information, with the original notice still attached for verification.
2. Suspected hit: Some conditions match, but batch, date, or region information is missing; the notification directly tells the user where to find missing identifiers.
3. Unable to determine: The source lacks sufficient structured fields, or photo recognition results are unstable; keep observing without drawing conclusions.

"No match" cannot equal "safe." It simply indicates that no matching evidence was found under covered sources, current data, and existing identifiers. This wording appears conservative, but it directly determines whether users will mistakenly stop further checks.

Image recognition is suitable for helping users transcribe labels, not for serving as a final verdict. OCR can provide candidate model numbers and barcodes, and then let users confirm; low-quality photos, packaging changes, and similar characters can all produce errors. The product should save fields confirmed by the user rather than reguessing from old photos every time.

Recall Records Are Revised, and Notifications Must Have Versions

The CPSC recall page explicitly notes that remedy information may change. After remedy methods, business contact status, or applicable scopes are updated, old notifications should not continue serving as the sole answer. Therefore, the collection layer must distinguish initial discoveries, content revisions, and temporary source unavailability, rather than treating the same notice as a new recall every day.

Event keys suitable for recall records typically consist of the source agency and source record ID. Each check saves a content summary and important field differences: scope expansions require rematching all related goods; layout-only modifications do not need to disturb users; remedy method changes should send corrections to those who previously received notifications. Notifications themselves must also record which version they were generated from.

If a source page fails briefly, the interface should display "this check was not completed" rather than "no new recalls." The onsite API error and self-healing guide explains why timeouts, rate limits, permissions, and upstream errors need to be handled separately; when applied to recall scenarios, coverage interruptions must especially not be disguised as safe states.

Users Want Next Steps, Not Just a Summary

Effective notifications should put the most important actions upfront: stop using, check batch, contact merchant, request refund, repair, or wait for further information. Actions must come from current official notices; do not let models supplement remedy suggestions on their own. For high-risk scenarios, the summary should be followed directly by the original source and official contact entry points.

Notification pacing must also distinguish severity levels and matching confidence. High-risk records with confirmed hits can be sent immediately; low-confidence suspected hits are better suited to enter a pending verification queue and update after users supply identifiers. Daily digests are suitable for general observation, but they should not delay clearly relevant safety notifications to reduce messages.

Merchant-facing products also require internal tasks: stopping sales of related items, locating inventory, finding orders, contacting affected customers, and recording disposition results. Collection only triggers tasks and cannot replace merchant permission controls over orders, warehouses, and customer identities. When integrating results into workflows, you can refer to the onsite unified data API design guide to tier original evidence, standardized fields, and business actions.

The Item List Itself Is a Sensitive Asset

Items owned by households may reveal health, infants, residences, and consumption habits, while merchant inventory and orders belong to operational data. Recall notification products should not default to infinitely storing photos, receipts, and complete orders simply for "safety purposes."

Version one can let users save only the minimum fields required to complete matching and allow deletion at any time. Automatic imports from emails, orders, or retail accounts require separate explicit authorization, displayed access scopes, and clarity on what data remains retained after synchronization stops. Whether photos continue to be stored after recognition is complete should also be determined by clear product rules.

For merchants, recall source data, internal SKU mapping, and customer contact information should be tiered and authorized. Personnel responsible for checking recalls do not necessarily need to see complete customer profiles, and personnel responsible for notifications should not be able to modify source evidence. Audit records should at least state who confirmed the match, which notice version was used, and what actions were triggered for which targets.

MVPs Should Verify the Matching Loop, Not Accumulate Notice Counts

A controllable pilot can cover just one regulatory source, one product category, and a small batch of voluntarily registered items. Manually review all candidates first, then observe which fields cause system failures. At this stage, how many years of historical notices have been indexed matters far less than whether a relevant notification can be accurately explained.

Four categories of metrics are recommended: the proportion of matchable records, fields needed for suspected hits, delivery and viewing of confirmed hits, and status from notification to completed remedy. False positives and false negatives must be reviewed separately, and missing source fields, product registration errors, and matching rule errors must also be separated. Only then will subsequent automation know whether to modify data, interactions, or rules.

This article discusses a data product design methodology and does not imply that EveryInfra has released a recall notification service. A true product recall notification service is not about scraping more notices, but about forming a verifiable closed loop of "official record—specific item—clear action—subsequent correction." Only when a system dares to express uncertainty can reminders be trusted over the long term.