Replies: 14 comments 16 replies
-
|
For context, as a public app if you made 1 million get calls a day, over a 7 day period your costs will be $3,400 USD. For the month, about $15,000 USD. It appears you can have a "Plus Tier" of $10,000 USD a month, which has |
Beta Was this translation helpful? Give feedback.
-
|
This decision is extremely disappointing. Many of us have already spent enormous time and money meeting compliance demands that go far beyond what’s reasonable for mid-sized developers. And every audit conveniently suggests that we could "just use AWS" — effectively selling internal solutions to problems Amazon itself creates. Adding this new pricing model on top of that feels like clear exploitation of a captive developer base. The SP-API has become essential for anyone working with Amazon — and now access to it turns into a privilege, not a partnership. Please rethink this direction. A more balanced, developer-friendly model — with fair tiers, lower entry costs, and recognition of existing compliance overhead — would show genuine respect for the ecosystem that helped build Amazon’s marketplace success. |
Beta Was this translation helpful? Give feedback.
-
|
Everything we do is geared around making Amazon money as we are focussed on growing Vendors and Sellers. We even run everything on AWS meaning they are earning through any compute we consume. It's a very aggressive pricing structure, prohibitively so. I would also love some transparency on how the big players are being charged as well. Will these be getting hugely discounted rates based on their relationships with Amazon? |
Beta Was this translation helpful? Give feedback.
-
|
This is so bogus. I use the SP-API as an Amazon seller myself, I wrote my own programs to assist me in A+ content uploads and generation for my large inventory catalog. I don't make calls every month, and to be charged $1,400 for access to something I don't use extremely frequently at the moment is so disappointing. I get it costs money for the servers and whatnot, but I mean $1,400 is a huge jump from something that is currently free for small developers and users like me. This is just absolute greed. |
Beta Was this translation helpful? Give feedback.
-
Attached is the pricing breakdown with "switch" points when you should optimally move to a different plan tier. This is for "public" apps. Amazon is not charging for private seller/vendor apps. |
Beta Was this translation helpful? Give feedback.
-
|
An Open Declaration to the Amazon SP-API Developer Ecosystem: "Trust nurtured for free should not become a sickle for harvesting" Dear Amazon Global Developer Relations Team: In the spring of 2019, Amazon extended an olive branch to developers worldwide, offering "zero-cost entry":
Over the past five years, we've responded to that trust with action: Our team worked over 300 sleepless nights developing a full-chain tool covering "intelligent product selection, automatic replenishment, and advertising," serving over 500 small and medium-sized sellers and helping them improve operational efficiency by 40%; We provided Amazon with over 200 API optimization suggestions, including "bulk order synchronization" and "multi-site inventory merging," which have been incorporated into official updates; Our tools have supported the automated processing of over 100,000 cross-border orders, indirectly increasing seller stickiness and GMV on the Amazon platform. We once believed that "free" was Amazon's sincerity towards developers and, more importantly, a belief in "ecosystem symbiosis"—without developer tools, sellers struggle to scale; without seller growth, Amazon's e-commerce moat will ultimately lose its luster. II. Today's "Charging Order": Not an "Upgrade," but a "Backstab" However, the email from the Solution Provider Portal in November 2025 extinguished all enthusiasm like a bucket of ice water: "Starting January 31, 2026, SP-API developers will need to pay an annual fee of $1400; GET request calls will be charged at $0.40 per 1000 calls." This is not "commercial optimization," but rather taking advantage of developers using code to nourish the ecosystem while simultaneously removing the lifeblood from their veins: For small teams, this is a "life-or-death fee": Our team's annual profit is less than $20,000, and the $1400 annual fee directly eats up 7% of our revenue—our plan to upgrade the AI product selection model now necessitates suspending hiring and even considering layoffs; For users, this is "commission per order": Our tool processes an average of 50,000 GET requests daily (only checking inventory and reading orders), resulting in an additional cost of 5 × 365 × 0.4 × 10 = $7300 (approximately 53,000 RMB) per year. Every order placed by a user results in a cut for us; the most absurd thing is the "double standard": Amazon never paid a penny when developing native features like "automatic pricing" and "smart advertising" using the SP-API; but when we use the same interface to serve sellers, we're choked by fees. Third, this isn't "ecosystem maintenance," it's shortsightedness that mortgages the future. Amazon might think, "Developers can't live without the SP-API, so they have to tolerate the price increase." But you've forgotten: Developers will vote with their feet: We've already started testing the Shopify API and eBay Trading API—their basic calls are still free, and their commission on new features is less than 2%; Sellers will leave: tools become more expensive, updates stagnate, and sellers will say, "Amazon's services are becoming increasingly difficult to use"; The industry will remember the lesson: from Facebook's Oculus commission to Apple's 30% App Store commission, and now to the SP-API fees, "free first, then harvest" has become the "standard script" for tech giants. Every time, it's the small and medium-sized developers who are most dependent on the ecosystem who suffer. Fourth, we don't want "charity," we want "equality." Amazon, you always say "developers are the core of the ecosystem." Then please prove it with actions: Withdraw the "one-size-fits-all" pricing: Basic API calls (such as order retrieval and inventory lookup) should be permanently free, with tiered annual fees (e.g., free for teams with annual revenue < $10,000); Share the growth dividend: If you insist on charging, at least 1% of the incremental GMV generated by sellers through SP-API calls should be returned to developers (currently there is no revenue sharing); Transparent communication: Inform developers of policy changes 12 months in advance, giving them a buffer period—instead of declaring our fate with a single email. Finally, I want to say a word to Amazon: "Trust cultivated for free is more precious than any traffic; revenue overdrawn from the ecosystem is more expensive than any fine." We have contributed to Amazon's "global e-commerce empire," and now we only ask: Don't let us, the bricklayers, die before the empire is built. We await your reply, and even more so, we await an Amazon that respects developers. A group of developers who breathe life into SP-API with code |
Beta Was this translation helpful? Give feedback.
-
|
How do I delete my public app? This fee is customer hostile. Imagine AWS with no free tier and a base charge of $1400 to get in the door. You can't because it's stupid. I don't mind paying a per usage fee like AWS, this is straight dumb and you lost me as a developer permanently. |
Beta Was this translation helpful? Give feedback.
-
|
As it stands, there are technical use cases that can not be resolved by developers. For example, an Orders API call will always have a larger number of GET requests because the Order and Order Items requires it. The volume of GET calls will be highly variable, meaning increased volume of orders will drive up those GET calls. Also, there is inconsistency in how marketplace requests work across the board, which also means various API endpoints will require more GET requests by market because datasets themselves do not have a market id column resident in the data. I think the point here is that while developers can certainly look to optimize, ultimately they are bound by the systems they are calling, and any lack of optimizations, conflicts, omissions, or errors is a cost born by the developer. Lastly, there is no observability baked into SP-API, meaning GET requests are aggregated at the app level. If you have say 20 seller and 20 vendor accounts using your system for calling the SP-API for reports or other resources, Amazon app usage reports can not tell you which seller/vendor ID requests are linked to. A seller using the Orders API is going to have significantly more GET requests than one who is only using Order Reports. As such, developers are forced to create their own observability capabilities because they will have no means to understand who is driving costs. |
Beta Was this translation helpful? Give feedback.
-
|
.... well, that almost completely destroys any useful marketplace of seller applications for small businesses, the ability to build applications without incurring significant costs, and several other points that other people have already brought up, and i'm sure there will be many, many more points brought up here as well. How do I ensure that my application is not a public facing application and will not incur this, as " looking to use a private selller or vendor app. Those are still $0. The costs apply to "public" apps." was said earlier? Like, how do you even account for this? There's no accounting APIs, no accounting dashboards, there's no systems in place for telling us how much we use currently, there's just suddenly BAM YOU'RE GOING TO GET CHARGED. There's no systems in place for telling us in the future how much we're using. (or is it buried somewhere in AWS? but most everything else in SPAPI is separate from AWS...) On top of that, I'm only seeing this because I happen to see a Github comment on this depot, it's not even emailed to my developer account that this is a thing that is happening? WHAT?! |
Beta Was this translation helpful? Give feedback.
-
|
I don't know if you're aware that an SP-API team was established in Shanghai, China. They seem incompetent and can't solve any problems. I suspect they were the ones who proposed the fees, and incredibly, no one protested that the fees were unreasonable. I opened a case repeatedly explaining the basis for these fees, and they replied that APIs also have maintenance costs, which is utterly ridiculous. This sudden announcement of fees is a bit brain-dead. And the fees are outrageous. If AWS charged like this, it would probably have gone bankrupt by now. |
Beta Was this translation helpful? Give feedback.
-
|
With so many problems, how dare they charge an annual fee? In developer groups, we often encounter server crashes or API issues, and feedback goes unanswered for one or two weeks. What is the rationale behind this mandatory charging? |
Beta Was this translation helpful? Give feedback.
-
|
I only see a couple of options. The first, and obvious one, is to apply differential pricing so customers (sellers) are charged more for Amazon channels over all the others. A more interesting one I've been exploring is to cease to be a developer providing multi tenanted services and instead provide an instance to each seller. In this manner software can be licensed to the the seller who can then use their own key for free. You would be removed from the Apps Store and do your own marketing. My cases with Amazon so far support this possibility. |
Beta Was this translation helpful? Give feedback.
-
|
How are they going to handle all of the Status 200 code "internal service error" responses? In my case with SPP support, Amazon admitted these are due to internal throttling issues on their side. We're now going to be charged for these? Should I start a reimbursement service for API calls 😭? |
Beta Was this translation helpful? Give feedback.
-
|
I wonder how many cases developers have opened about charging and cost mitigation. I suspect a great many and hopefully there is some unease at Amazon HQ. Amazon needs someone to lead developer relations, support and API offerings with a goal to get developers onside so they help sellers, vendors and affiliates to partner with them. Judging by Amazon’s arrogance, this won’t be anytime soon, but if they keep f*****g people off, one day they may have to. |
Beta Was this translation helpful? Give feedback.

Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
https://developer.amazonservices.com/spp-announcement
Starting January 31, 2026, all third-party developers integrated with SP-API will be charged an annual subscription fee of $1400 USD. This subscription includes access to the Solution Provider Portal, support services, and production usage of SP-API. New third-party developers will be charged after their first production SP-API service call, while existing third-party developers will see charges begin on this date.
Starting April 30, 2026, we will implement a monthly API usage fee based on your GET API call volume. To help you make an informed decision, you have access to a fee preview on the Solution Provider Portal, where you can choose from 4 tiers: Basic, Pro, Plus, and Enterprise, allowing you to scale usage based on your needs. The Basic tier has no additional charge. To support developers in managing your usage efficiently to lower your fees, we’ve published a Call Optimization Guidance Page with best practices and tools to help you make more efficient API calls, and we are providing you with six months advance notice so you have time to make desired optimizations to your API calls.
Monthly API Usage Tier Structure
To support developers across all stages, from startups to enterprise-level applications, we are introducing a tiered usage model. All third-party developers default into the Basic Tier, which includes 2.5 million GET calls per month at no additional charge beyond the annual subscription. If no changes are made, your account will remain in the Basic tier. You’ll be able to choose other tiers if they better fit your needs directly through the Solution Provider Portal.
Beta Was this translation helpful? Give feedback.
All reactions