Migration assurance
getOrderAddress replacement: migration guide and scanner checklist
getOrderAddress replacement explains what replaces getOrderAddress, the removal date, the migration risks to validate, and how API Migration Guard detects the pattern.
- Target keyword: getOrderAddress replacement
- Removed: getOrderAddress
- Replacement: getOrder with includedData=RECIPIENT
- Removal date: March 27, 2027
TL;DR
| Deprecated item | Removal date | Replacement | Migration risk | Scanner detection |
|---|---|---|---|---|
| getOrderAddress | March 27, 2027 | getOrder with includedData=RECIPIENT | Recipient address parity can fail when role access or includedData is not validated. | AMZ-ORD-OPERATION-001 |
Official status
Amazon documentation lists getOrderAddress as in-scope for this migration. Use the official source before code freeze because deadlines and replacement details can change.
Amazon Orders API migration guide Amazon SP-API deprecation schedule
Production Orders validation plan
Orders migrations need same-order parity checks because the v2026 model consolidates data that v0 teams often fetched through separate buyer, address and item calls. Treat each finding as a prompt to validate a captured order before code freeze.
| Validation area | Production proof to collect |
|---|---|
| includedData | Record which paths require BUYER, RECIPIENT and ITEMS and confirm role approval for each marketplace. |
| Payload parity | Compare one shipped, one unshipped and one cancelled order against the legacy consumer contract. |
| Pagination | Exercise paginationToken with the original search filters and confirm retry behavior for expired tokens. |
| Downstream jobs | Re-run tax, fulfillment, notification and support workflows that consume order fields. |
Recipient address redaction cases
getOrderAddress replacement work should separate request-shape bugs from legitimate redaction. A page can pass the operation migration and still fail shipping, support or tax workflows if address-line and phone expectations are not documented per order type.
| Recipient field | Request shape | Common redaction case | Validation note |
|---|---|---|---|
| recipient.deliveryAddress.name | includedData=RECIPIENT | Restricted address portions depend on role, fulfillment and marketplace. | Validate with one FBA and one FBM order where available. |
| recipient.deliveryAddress.addressLine1/2/3 | includedData=RECIPIENT | Tax roles can still be insufficient for some restricted address data in specific marketplaces. | Compare only fields the app truly consumes. |
| recipient.deliveryAddress.phone | includedData=RECIPIENT | Phone can be suppressed after it is no longer needed for fulfillment. | Do not treat a suppressed phone after delivery as a failed migration. |
| recipient.deliveryAddress.postalCode | includedData=RECIPIENT | Postal-code availability differs from full address-line availability. | Keep postal-code checks separate from name/address-line checks. |
Removed resource and replacement
| Old resource | Replacement | Deadline | Validation outcome |
|---|---|---|---|
| getOrderAddress | getOrder with includedData=RECIPIENT | March 27, 2027 | Recipient address parity can fail when role access or includedData is not validated. |
What breaks
| Area | Breakage |
|---|---|
| Code pattern | Legacy Orders v0 call or endpoint usage for getOrderAddress. |
| Payload or schema | v2026 responses use changed field names, includedData sections and different enum semantics. |
| Permission or data access | Buyer and recipient PII require approved roles and includedData, not an old RDT workflow. |
| Pagination, status or field mapping | NextToken becomes paginationToken and can expire after 24 hours; status and fulfillment values need parity checks. |
Before/after example
The example is intentionally small so the migration shape is visible in a code review.
Before:
const address = await client.getOrderAddress(orderId);
After:
const order = await client.getOrder({ orderId, includedData: ['RECIPIENT'] });Scanner detection
| Rule ID | Severity | Evidence pattern | False positive condition | Validation step |
|---|---|---|---|---|
| AMZ-ORD-OPERATION-001 | BLOCKER or HIGH depending on evidence type | getOrderAddress | Documentation, comments, generated clients or test fixtures can require manual review. | Confirm the code path is production runtime, not only docs, comments or generated vendor output. |
Migration checklist
- Confirm the code path is production runtime, not only docs, comments or generated vendor output.
- Replace the legacy operation with the v2026 operation and required includedData.
- Compare same-order v0 and v2026 payloads in the Orders Payload Parity Validator.
- Re-scan and confirm Orders rule IDs are fixed or explicitly accepted as manual risk.
Common mistakes
- Treating includedData as a search filter instead of response data selection.
- Assuming RDT migration alone restores buyer or recipient fields.
- Stopping pagination or mapping enums without comparing representative order payloads.
Sample report preview
The public sample report shows the same evidence shape used by paid reports: rule ID, severity, file location, redacted evidence, migration mapping, validation step and quality gate.
FAQ
What is the replacement for getOrderAddress replacement?
getOrder with includedData=RECIPIENT
Does API Migration Guard call Amazon?
No. It statically scans source and validates pasted samples without Amazon credentials.
What proves the migration is safe?
A re-scan with no blocking Orders findings plus same-order payload parity for buyer, recipient, item, status and fulfillment fields.
Official sources
Validate getOrderAddress replacement in your source
Run a static scan, review the sample report shape, then unlock the detailed migration report when the evidence is useful.