The SP-API Deprecation Calendar: What Breaks in 2026 and 2027

Amazon deprecates an SP-API operation long before it removes it, often by two years or more. In between, the endpoint keeps working perfectly. No warning header, no throttled responses, nothing in your logs. The only signal is a line on a documentation page that nobody on your team has open.

Then the removal date arrives and your order sync — the one that has run untouched for three years — starts returning errors on a Tuesday morning.

As of August 2026, three removals are worth putting in a calendar. Two of them affect nearly every seller integration.

This is the one that changes your code the most, and it's also a genuine upgrade rather than a lateral move.

The v0 model was listFinancialEvents: a bundle of event lists by type — shipment events, refund events, service fee events, adjustment events — each with its own shape. Building a per-order profit figure meant walking every event type, matching on order ID, and knowing which nested field carried the money for each.

Finances 2024-06-19 replaces that with listTransactions: a single ledger of transactions, 500 per page, each with a breakdown tree, a ProductContext carrying ASIN, SKU and quantity, and relatedIdentifiers linking back to the order and settlement. One shape instead of a dozen.

What actually changes in your integration:

• Your parsing is rewritten, not adjusted. Event-type branching disappears in favour of walking a breakdown tree. Plan a real migration, not a find-and-replace.
• Per-item attribution gets easier. ProductContext gives you ASIN and SKU directly, where v0 often forced you to join back to the order.
• Transaction status matters. Transactions carry RELEASED and DEFERRED states. If your P&L counts deferred money as settled, your numbers will run ahead of reality.
• Throttling is tight. Roughly 0.5 requests per second with a small burst allowance, so a historical backfill needs pacing — the same discipline as any SP-API bulk pull.

Note that listFinancialEventGroups in v0 is not deprecated. It still enumerates payout groups, and feeding a group ID into listTransactions is a clean way to reconcile a payout.

If you use the widely-used Python SP-API client, the new version is selectable directly — Finances(version="2024-06-19") — so the client library is unlikely to be your blocker.

Orders v0 is the endpoint almost every seller integration is built on, and it has a removal date roughly eighteen months out from this writing. Nothing breaks yet, and there's a real risk of assuming someone will handle it later.

Two practical points. First, your order sync is rarely one call — it's getOrders, getOrderItems, the buyer-info paths, and the address paths, plus whatever restricted-token wrapping you've built around them. Migrating means re-verifying all of it, including the restricted data token flow, because PII paths are exactly the sort of thing that shifts between versions.

Second, this is a good moment to fix things you already know are wrong. Most order syncs carry at least one of these: pulling on CreatedAfter instead of LastUpdatedAfter and therefore missing status changes on older orders, or assuming the order ID is globally unique. A version migration is the cheapest time to correct both.

The nearest date, and the easiest fix. The older settlement report variants — the original flat file and the XML form — are removed on 2026-11-11. Parse GET_V2_SETTLEMENT_REPORT_DATA_FLAT_FILE_V2 instead.

Settlement reports are auto-generated by Amazon rather than requested, so you discover them through getReports and download what's there. If your code filters that listing by report type — and it almost certainly does — check that the filter includes the V2 type. That one-line filter is the whole migration for most integrations, and it's also the reason this one gets missed: nothing errors, the report list just quietly stops matching and your reconciliation goes stale.

Reports are asynchronous, which is its own source of bugs; if you're touching this code anyway, the request-poll-download-decompress pattern is worth a re-read.

Deprecations are announced on a page, not in your logs. Three habits close that gap:

• Put the removal dates in the same calendar as your certificate renewals. Not a ticket in a backlog — a dated event with an owner, six to eight weeks before the removal.
• Pin API versions explicitly in code. If your client library picks a default version for you, a silent upgrade is as disruptive as a removal. An explicit version string makes the dependency greppable.
• Re-read the deprecations page quarterly. It takes ten minutes and it's the only authoritative source. Amazon also adds entries between announcements, so a one-time read is not enough.

The failure mode here isn't technical difficulty — none of these migrations is hard. It's that a working integration generates no pressure to change until the day it stops working, which is always a day you didn't plan for.

When is Amazon SP-API Orders v0 being removed?

Orders v0 was deprecated on 2026-01-28 with removal scheduled for 2027-03-27, according to Amazon's SP-API deprecations page as of August 2026. It continues to work normally until then, which is why the migration is easy to postpone.

What replaces listFinancialEvents in SP-API?

The Finances 2024-06-19 API's listTransactions operation. It returns a single paginated transaction ledger with breakdown trees, per-item ProductContext and relatedIdentifiers, replacing v0's separate lists of typed financial events. Finances v0 listFinancialEvents is scheduled for removal on 2027-08-27.

Is listFinancialEventGroups deprecated too?

No. The v0 listFinancialEventGroups operation is not deprecated and remains useful for enumerating payout groups, whose group IDs you can feed into listTransactions.

Which settlement report should I parse now?

GET_V2_SETTLEMENT_REPORT_DATA_FLAT_FILE_V2. The older flat-file and XML settlement report variants are removed on 2026-11-11. Check that any report-type filter in your download code includes the V2 type.

Will Amazon warn me before an endpoint is removed?

Not through the API itself. Deprecated operations keep responding normally right up to the removal date, with no warning headers. The SP-API deprecations documentation page is the authoritative source, and it is worth re-reading quarterly.