THE SHORT ANSWER
Pin production exports to the specification your destination currently accepts. Explore draft fields in a separate sample workflow, record the differences, and require a successful validation and partner check before moving an experimental mapping into the recurring feed.
Store the contract with the mapping
A mapping is incomplete without a destination and a version. A field called price can have different structures across interfaces; a syntactically valid value can still violate the contract you intended to follow. Save the source field, destination field, transformation and specification reference together.
Give the mapping a meaningful revision identifier. When someone asks why yesterday’s export differs, you should be able to identify the rule and contract used at that time. A link to a changing documentation homepage is less useful than a dated review record.
Keep experiments out of recurring releases
OpenAI’s product feed documentation distinguishes Stable production fields from Draft planning material. Treat that distinction as a release boundary. An attractive draft capability should not silently change the export your merchant relies on every morning.
Build a small experimental sample with clearly labelled assumptions. Compare its shape with production output and list what the new fields require from the source catalog. This often reveals an operational gap, such as missing evidence or an unclear data owner, before it becomes an integration failure.
Test the difference rather than the entire universe
Choose representative records that exercise the changed contract: an ordinary product, a variant, a missing optional value, a non-ASCII title and a market-specific price. Add the edge case that motivated the upgrade. Save the expected outcome for each sample.
Separate parsing, field validation and destination acceptance in the test report. A parser accepting a new column does not establish that the destination processes it. If a partner test is unavailable, report that limitation explicitly instead of marking the release fully verified.
Make rollback a data decision
A rollback should restore a known mapping and a known source snapshot. Re-running an old rule against a changed source may produce different results, so retain enough evidence to explain that distinction. Avoid restoring expired prices merely because an older file passed validation.
Define who approves an upgrade and what stops the rollout. A sudden increase in missing identifiers or an unexpected reduction in products deserves investigation before release. Keep the decision log concise: change, evidence, owner and recovery path.
ILLUSTRATIVE WORKED EXAMPLE
Make it concrete.
Illustrative example: a team experiments with an additional descriptive field in a draft schema. It stores that output separately, discovers that half the source values lack evidence, and keeps the existing production mapping until the source owner resolves the gaps and the destination supports the field.
Your practical checklist
- Record destination and version on every mapping.
- Keep draft exports separate from production files.
- Choose representative records for changed behavior.
- Distinguish local validation from destination acceptance.
- Retain a known mapping and usable recovery snapshot.
Common questions
Should every documentation change trigger a migration?
No. First assess whether it changes your accepted contract or enables a necessary capability. Then schedule and test the migration.
Can permissive parsers hide a problem?
Yes. Accepting extra fields locally can conceal that a destination ignores or rejects them. Test the actual receiving interface.
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 ↗