For roughly a decade, Amazon’s Selling Partner API was free. As of 2026 it is not. Annual subscription charges began on 31 January 2026 and monthly usage fees followed on 30 April 2026. If you sell on Amazon and have never seen a line item for this, that is not because you are exempt — it is because the cost is sitting inside somebody else’s invoice, and it is about to meet your Q4 call volume.
Here is what actually changed, who pays, and the audit worth doing before peak season multiplies every number below.
What Amazon put a meter on
The charges apply to GET requests — the calls that read data out of Amazon. Orders, inventory levels, pricing, reports, catalogue lookups. Write operations are explicitly excluded: PUT, PATCH and POST requests remain unmetered and unlimited, subject to standard rate limits.
That asymmetry is the whole design. Amazon is not charging you to run your business on its platform; it is charging for the polling that third-party software does to keep dashboards current.
| Tier | Monthly GET calls included | Monthly fee |
|---|---|---|
| Basic | 2.5 million | No additional fee |
| Pro | 25 million | $1,000 |
| Plus | 250 million | $10,000 |
| Enterprise | Custom | By negotiation |
Who pays — and why your invoice may still change
The fees land on third-party developers building applications for sellers. A seller who calls the API only for their own business is exempt.
That exemption reads like good news and mostly is not, for a simple reason: almost nobody calls the API directly. Your repricer calls it. Your inventory tool calls it. Your analytics dashboard, your accounting connector, your PPC platform, your 3PL’s integration — every one of those is a third-party developer with a new cost base and a pricing page they can edit.
So the practical question is not “do I pay Amazon?” It is “which of my vendors just had their margin compressed, and how are they recovering it?” There are only three answers, and they are all visible if you look:
- Raise prices. The honest one. You see it as a subscription increase or a new usage tier.
- Reduce polling frequency. The invisible one. Your data gets staler — inventory syncs every 30 minutes instead of every 5, pricing signals arrive late. Nothing on your invoice changes, but your repricer starts reacting to yesterday’s competition.
- Absorb it. Fine for a well-capitalised vendor, a solvency question for a small one. Worth knowing which of your tools is which.
The second answer is the dangerous one, because it degrades silently and it degrades hardest exactly when call volume is highest — which is Q4.
Rate limits have not gone away
Metering is a cost ceiling. Rate limits are still a throughput ceiling, and they remain per-endpoint with their own burst quotas:
| Endpoint group | Rate (req/sec) | Burst |
|---|---|---|
| Catalog Items | 5 | 40 |
| Inventory | 2 | 30 |
| FBA Inbound | 2 | 30 |
| Notifications | 1 | 5 |
| Finances | 0.5 | 30 |
| Product Pricing | 0.5 | 1 |
| Reports | 0.0222 | 10 |
| Orders | 0.0167 | 20 |
Note what these numbers do to the pricing tiers. Orders at 0.0167 requests per second is roughly one call per minute. You cannot burn through 2.5 million monthly GET calls on Orders alone — you get there by polling many endpoints across many marketplaces, continuously. Which is precisely what a multi-tool stack does.
The push model is now a cost decision, not just an architecture one
There has always been a better way to learn that an order arrived than asking every minute whether one has. Amazon’s Notifications API pushes events to you instead of you polling for them.
Before metering, polling versus push was an engineering preference. Now it has a price. Every poll that returns “nothing changed” is a billable GET call that bought you no information. In a stack built on 60-second polling across half a dozen endpoints, the majority of your metered volume is that: paid confirmations that nothing happened.
If you commission or maintain your own integration, this is the single highest-leverage change available to you, and it costs nothing but development time. The no-code automation cost model covers the same trade-off for sellers who buy rather than build.
The pre-Q4 audit
- List every tool with API access to your seller account. Include ones you stopped using. Revoked-but-still-authorised applications keep polling and keep costing.
- Ask each vendor two direct questions. “Has your pricing changed as a result of SP-API metering?” and “Has your polling frequency changed?” The second question is the one they are less likely to volunteer.
- Check your data freshness, not your dashboard. Change a price in Seller Central and time how long your tool takes to reflect it. Do this now, and again in November. A gap that opens between the two is your answer.
- Move what you can to Notifications. Order events, listing state changes, fee changes. Anything event-shaped should not be polled.
- Verify backoff behaviour. Under Q4 load, throttling is not an edge case, it is a Tuesday. Confirm your integration reads Retry-After and backs off exponentially instead of hammering.
- Price the alternative. If a vendor’s increase is steep, a direct integration now has a knowable cost: $1,400 a year plus your own call volume. For some sellers that maths has genuinely flipped.
Honest risk assessment
Two things worth saying plainly.
First, if you are a small seller with two or three tools, this probably costs you very little directly and may cost you nothing. The realistic exposure is a vendor price increase in the tens of dollars per month, not a structural problem.
Second, the degradation risk is real but not universal — plenty of vendors were already push-based and are unaffected. The point of the audit is not to assume the worst; it is that stale data during Black Friday is expensive in a way that is very hard to detect after the fact. You will see the lost sales. You will not see the reason. If your margin per unit is thin to begin with, the fee layers already eating into it leave little room for a pricing error on top.
An integration that fails loudly is an operational problem. An integration that quietly serves you five-minute-old prices during the highest-traffic week of the year is a margin problem, and it does not show up in any error log.
Verification note
Fee structures and rate limits above are drawn from reporting on Amazon’s developer announcement and from published SP-API limit documentation as of mid-2026. Amazon revises both without broad notice. Confirm current figures in Seller Central and the official SP-API documentation before making a build-versus-buy decision on these numbers.
Haftalık bülten
Pazaryeri ve e-ihracatta bu hafta ne değişti?
Komisyon oranları, mevzuat ve algoritma değişikliklerini haftada bir, tek e-postada özetliyorum. Reklam yok, tekrar yok — istediğiniz an tek tıkla çıkabilirsiniz.
