THE SHORT ANSWER
A full-snapshot pipeline repeatedly publishes a complete catalog state, rather than treating each file as an unexplained fragment. OpenAI’s checked file-upload guidance uses SFTP delivery and stable snapshot files. Build validation, release selection and delivery evidence around that contract.
Define the complete catalog boundary
Write down which products, markets and source systems belong in the snapshot. If multiple files are used, record the complete expected file set. A missing source should be treated as an operational exception, not quietly accepted as a smaller catalog.
Keep the distinction between an intentional removal and an incomplete export. The destination’s retention and withdrawal behavior must be understood from its current documentation. Your own release checks should detect suspicious drops before the files leave the workflow.
Keep a release manifest
For each delivery, save the source snapshot, artifact names, record counts, creation time and hashes. If the catalog is sharded, include the expected shards and their counts. A manifest makes it easier to answer whether the destination received the intended release or an accidental mixture of generations.
Use stable naming and predictable source-to-shard assignment when the delivery contract calls for them. Avoid a manual process in which every run invents new files and leaves old copies behind. A directory that cannot be explained is difficult to debug when ingestion behaves unexpectedly.
Verify each delivery layer separately
A local validation pass, a successful transfer and destination ingestion are different results. Record them separately with timestamps and relevant references. A network success should not automatically be displayed as catalog acceptance.
Test interrupted transfers, unavailable sources and invalid records in a controlled environment. Keep retries idempotent where possible and ensure a retried job cannot silently substitute a different release. Recovery should preserve enough context for a person to understand what happened.
Choose a cadence your operation can support
The checked guidance recommends predictable snapshots at least daily. Your actual update design should also account for inventory volatility, destination capabilities and the cost of validation. Faster schedules are useful only when the source and pipeline can supply dependable changes.
Estimate the review and operational effort before committing to a cadence. The cost calculator can make those assumptions visible. For recurring operation, evaluate whether a workflow offers durable jobs, release history and delivery evidence rather than only a download button.
ILLUSTRATIVE WORKED EXAMPLE
Make it concrete.
Illustrative delivery: a release expects four shards and 40,000 variants. The third source fails, leaving 30,000 rows. The release guard holds publication, preserves the last healthy release and records the failed source. A retry rebuilds the complete manifest before delivery resumes.
Your practical checklist
- Define the complete snapshot boundary.
- Record expected files, counts and hashes.
- Detect abnormal catalog drops.
- Separate transfer from ingestion evidence.
- Test retry and recovery before increasing cadence.
Common questions
Is a successful SFTP upload the same as acceptance?
No. It establishes a transfer result. Destination processing and acceptance require their own evidence.
Can I assume omitted products disappear immediately?
No. Confirm the destination’s current retention and withdrawal behavior and design explicit removal handling where required.
Sources & scope
Official references checked 29 October 2026. Examples are illustrative, not customer results. Platform requirements can change; use current destination documentation for implementation decisions.
Our editorial method & corrections ↗