Migration assurance
Orders payload parity validator
Confirm how a migrated Orders v2026-01-01 response compares with the v0 response your integration relied on. The validator inventories v0 fields, classifies supplied v2026-01-01 fields, flags remapped status and fulfillment enums, and identifies buyer or recipient fields that require matching includedData requests.
- Input: One Orders v0 payload and one v2026-01-01 payload
- Output: Field inventory: mapped, moved, semantically changed, unavailable or not verified
- Method: Deterministic structural diff. No code executed, no credentials.
What it checks
Every v0 leaf field is inventoried and classified as mapped, moved, semantically changed, unavailable or not verified in the supplied v2026-01-01 payload. Missing fields are flagged, known enum remaps (OrderStatuses to fulfillmentStatuses, MFN/AFN to MERCHANT/AMAZON) are surfaced, and buyer and recipient fields are identified as restricted-data gaps that require includedData, role/access and redaction checks before a root cause is assigned.
Why parity matters
A migration that compiles can still silently drop a field your downstream systems need. Parity checking catches those gaps before cutover, not after.
Supported input formats and limits
| Input | Format | Limit |
|---|---|---|
| Orders v0 payload | JSON object copied from a representative response | Maximum 2 MB per payload, 4 MB total per comparison |
| Orders v2026-01-01 payload | JSON object for the same order after migration | Maximum 2 MB per payload, 4 MB total per comparison |
Redaction behavior
The result redacts common buyer and recipient PII values before display. The validator classifies fields and paths; it does not need Amazon credentials and does not call Amazon.
Exact checks
- Inventory v0 leaf fields and classify supplied v2026-01-01 coverage.
- Detect mapped, moved, missing, semantically changed, unavailable and not-verified fields.
- Surface Orders status and fulfillment enum changes.
- Identify missing buyer/recipient fields as MISSING_RESTRICTED_DATA rather than assuming one cause.
- Ask the team to verify includedData, approved restricted roles and whether the uploaded payload was redacted.
- Flag unexpected v2026-only differences separately from lost v0 fields.
Sample input
v0: {"AmazonOrderId":"123-456","OrderStatus":"Shipped","BuyerInfo":{"BuyerEmail":"[redacted-buyer-email]"}}
v2026: {"orderId":"123-456","fulfillmentStatus":"SHIPPED","buyer":{}}Sample output
{
"status": "PARTIAL",
"missing": [{
"path": "BuyerInfo.BuyerEmail",
"classification": "MISSING_RESTRICTED_DATA",
"verification": [
"Verify includedData contains BUYER",
"Verify the application has an approved restricted role",
"Verify the supplied payload was not redacted"
]
}],
"enumRemaps": [{"from": "Shipped", "to": "SHIPPED"}]
}PASS, PARTIAL and FAILED logic
| Status | Meaning |
|---|---|
| PASS | Supplied sample fields reconcile without missing required coverage. |
| PARTIAL | Some fields require manual or includedData verification. |
| FAILED | Required fields are missing, unavailable or semantically unsafe in the supplied sample. |
Known limitations
- A same-order sample does not prove every production order shape.
- Dynamic downstream transformations outside the supplied JSON are not observed.
- Unavailable Amazon fields still require product/business sign-off.
Pricing entitlement
The free product shows validator scope. Single unlocks one module-specific validator; Bundle and Agency unlock all three module validators according to the entitlement matrix.
Frequently asked questions
Do you send my payloads to Amazon?
No. Both payloads are compared within the validator service and are never sent to Amazon.
Official sources
Last reviewed: 2026-07-02.
Open the interactive scanner: /app#/validators