FSIS Recall API records need ingestion and revision lineage

Treat every retrieval as a source event

The direct answer is that an ingestion job should retain enough detail to reconstruct what it asked for and what FSIS returned. Preserve the endpoint and documented version, request parameters and filters, pagination or cursor state, retrieval time and time zone, response status and headers where useful, payload or immutable snapshot under the organization's retention rules, digest, schema version, record identifiers, item count, parser version, validation result, and any partial or failed pages.

A green job status is insufficient if the process skipped a page, reused a stale cache, truncated a field, changed a date or identifier, or silently accepted an unexpected schema. Monitoring should separate transport availability, complete retrieval, parse success, record-level validation, deduplication, storage, downstream distribution, and operator review. Each failure state needs a retry or escalation path that does not manufacture completeness.

Revisions and corrections should not erase the first alert

Agency records can be updated as a recall develops. Store each observed version with its retrieval time and a field-level or otherwise explainable change record. Identify added or removed products, labels, production dates, establishment information, distribution details, classifications, public-health descriptions, status, attachments, and correction notes only when the source provides them. Unknown fields and absent values should remain distinct from confirmed negatives.

Downstream systems should know whether a change came from FSIS, a parser correction, an internal product match, or an operator annotation. If a later record narrows or expands scope, preserve the earlier actions and the evidence available when they were taken. Do not backdate the new value into the original alert. The impact workflow should identify which open cases, products, facilities, customers, notices, and reports need reassessment.

Map the public record to internal lot evidence explicitly

A recall description may name products, establishments, labels, date ranges, or distribution context, while an organization operates with item masters, supplier codes, purchase orders, production lots, transformations, inventory locations, shipments, customers, and consumer channels. Preserve the exact source attribute used for each match, match method, confidence or ambiguity, reviewer, excluded candidates, and effective population. Never turn a fuzzy name match into a confirmed lot relationship without supporting evidence.

Keep source ingestion, applicability assessment, lot and shipment tracing, inventory hold, production stop, customer or regulator communication, public notice, retrieval or return, destruction or disposition, effectiveness check, reconciliation, and closure as separate records. The API can start or update awareness; it cannot prove those actions occurred. Quantity and reach evidence should reconcile to independent inventory, production, shipment, communication, and disposition records.

Test gaps before depending on the feed

Replay a representative period with multiple pages, a duplicate record, a corrected item, a missing field, a late update, a network failure, a schema surprise, and an internal product name that maps to several lots. Verify restart behavior, idempotency, source snapshots, alert latency, change detection, match review, case creation, downstream receipts, unresolved exceptions, and historical reconstruction. Include an API outage and a documented manual fallback.

The official FSIS page supports the existence of the Recall API developer resource. It does not establish API uptime, schema stability, a customer's ingestion completeness, product or lot applicability, notice delivery, inventory control, product recovery, regulatory sufficiency, response effectiveness, closure, or food-safety outcome. Qualified food-safety, regulatory, quality, operations, supply-chain, data, information-technology, communications, and legal owners retain those decisions.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Food Traceability Ledger will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.