Amazon is removing three SP-API versions. Each migration is one week, $500 fixed.

Amazon removes the Flat File and XML settlement reports, GET_V2_SETTLEMENT_REPORT_DATA_FLAT_FILE and GET_V2_SETTLEMENT_REPORT_DATA_XML, for sellers in all marketplaces. Both have been deprecated since 2025-03-17, and the removal was first set for 2026-03-25 before Amazon moved it. The replacement, GET_V2_SETTLEMENT_REPORT_DATA_FLAT_FILE_V2, is available now, and there is no XML replacement. Settlement reports can't be requested: Amazon schedules them and you find them with getReports. So code still looking for the old type names can fail in the worst way, with settlements that quietly stop arriving. That's Amazon's deprecation schedule as of October 2026.

No, and that's the trap. V2 collapses the price and fee columns into amount-type, amount-description and amount, and Amazon's own field mapping says related amounts may be combined. Amounts also come in local formats, so an EU marketplace sends 95,00 where you expected 95.00. V2 needs the Finance and Accounting role too, where the old flat file also worked with Inventory and Order Tracking or Amazon Fulfillment. Swap the type name alone and you get a report your parser doesn't understand. That's why this sprint ends in a parity check rather than a find-and-replace.

Because until 2026-11-11 your current code still has the old report to run on, and the V2 parse can be checked against it. From that date Amazon makes the old types unavailable for sellers, so if you switch afterwards, the only baseline left is whatever your pipeline already stored. As of 9 October 2026, the date is about a month away.

Fewer calls, with different shapes. getOrders becomes searchOrders, and getOrder, getOrderItems and the buyer-info and address calls fold into getOrder, with includedData choosing which blocks come back (BUYER, RECIPIENT, PROCEEDS, FULFILLMENT, PACKAGES and others). NextToken becomes paginationToken and expires after 24 hours, and searchOrders takes exactly one of createdAfter or lastUpdatedAfter. Values change too: Canceled is CANCELLED, MFN is MERCHANT, AFN is AMAZON, and money moves into proceeds breakdowns. Only six v0 operations are on the removal list. confirmShipment, updateShipmentStatus, getOrderRegulatedInfo and updateVerificationStatus aren't on it.

Not on v2026-01-01. Amazon's words: “Accessing PII with the Orders API v2026-01-01 does not require a Restricted Data Token (RDT).” Your restricted role still decides what comes back. Buyer email and the recipient's phone need Direct-to-Consumer Shipping. Buyer name and the restricted parts of the address can also come through Tax Invoicing or Tax Remittance, depending on fulfillment channel, but in Japan and Singapore the tax roles don't get the buyer's name. Dropping the RDT layer is the easy half of the sprint. Re-checking every field against your roles is the half that matters.

The list call might. searchOrders defaults to 0.0056 requests per second with a burst of 20, about one call every three minutes once the burst is spent, where v0 getOrders allowed 0.0167. includedData makes up for it: items, buyer and recipient data can come back with the search results instead of one getOrder call per order, and getOrder itself stays at 0.5 per second with a burst of 30. The sprint re-paces your loop for your real volume.

You get one ledger instead of typed event lists. listTransactions returns transactions with breakdowns, contexts and related identifiers, and it replaces all three listFinancialEvents calls. Where you used the ByOrderId or ByGroupId versions, filter with relatedIdentifierName set to ORDER_ID or FINANCIAL_EVENT_GROUP_ID. The traps are in the reference. If postedAfter and postedBefore are more than 180 days apart, “the response is empty”. The operation “can return empty pages”, so you page until nextToken is null. And events “might not include orders from the last 48 hours”. It defaults to 0.5 requests per second with a burst of 10, and it needs the Finance and Accounting role.

No. Only listFinancialEvents, listFinancialEventsByGroupId and listFinancialEventsByOrderId are on Amazon's removal list for 2027-08-27. listFinancialEventGroups stays, and its group IDs are what you pass to listTransactions to see which transactions make up a payout.

The old and new versions run against the same seller account over a date range you choose, and I compare them record by record and in total: orders and statuses, settlement and payout totals, fee lines. Every difference either gets a named reason, such as a renamed value, a combined amount or an order inside Finances' 48-hour window, or it gets fixed. You get the report, so switching over is a decision made on evidence.

One week covers one code path per API: the change, the parity check and the deploy. If Orders is called from several services, or there's no account I can test against, I'll say so before you pay and quote it as a project instead.

Yes, as three sprints at $500 each, booked in deadline order: settlement first, then Orders, then Finances. Doing Orders and Finances well ahead of their dates leaves room if Amazon moves a date again. It has already moved the settlement removal once.

No. The parity check runs through your existing app credentials against an account you choose. I never ask for a Seller Central password.