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 is too expensive. |
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.
-
|
Looks like the audits are getting more frequent and it's impossible to get an explanation, just cut and paste of nonsense and reference to policies. Twice a year now for me. Will it become 3 times a year or maybe monthly? |
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.
-
|
Excellent point, this is something I will be bringing up with the FTC for anti-trust and my state Senators. I live in Washington State, I'm sure they'll be interested to hear how Amazon is treating us. |
Beta Was this translation helpful? Give feedback.
-
|
Great! This step is absolutely crucial! As Washington State is home to Amazon's headquarters, your appeal to the state senator and the FTC's antitrust department will definitely hit the core concerns precisely – this one-size-fits-all high-fee model not only squeezes the space for us developers to survive, but also deprives a large number of sellers of diverse tool options, ultimately damaging the fairness of the entire Amazon ecosystem. |
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.
-
|
@bbenda02 to be clear, in your use case you should be looking to use a private selller or vendor app. Those are still $0. The costs apply to "public" apps. |
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.
-
|
I didn't even receive an email. I only happened to catch this because I subscribe to this github repo. I'd be slammed with a $1400 attempt at charging my account and no idea why had I not seen this. It is absolutely unbelieveable the short time frame, and the extremely high minimum access tier. And there are no tools in place, whatsoever for auditing usage, so if you want to know what you're using you're going to have to write the code to audit it yourself. Well, I'd guess Amazon has the tools to audit it, so they can charge for it, but they don't make that available to us, in any way that I'm aware of anyway. Yeah, I'll certainly be pulling the dozen or so people that use my app, and making it for myself only. And definitely considering dumping the platform. Most of the people that I know already have thanks to other changes on the platform already, but this will take most of the remaining people that I know off. I'm not sure if I'll leave, but if at some point this leaves me trapped using Seller Central's absolutely abyssmal interface for doing things, that's a definite. The Seller Central interface is not a serious interface. That cannot be used by anyone who is serious about doing any amount of volume. If anyone actually is, my respect to them for the amount of pain that they can tolerate, because it is the most user hostile thing I've seen in a VERY long time, and it's getting worse every update. |
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.
-
|
Creating a private app is well documented by Amazon, but it is limited to the seller or vendor, it cant be used at scale like a public app. For sellers, vendors, brands, the private app is the path to go down assuming the use case fits the limits for authorizations (10). For everyone else, there is no escaping the program or usage fees, as it is documented. |
Beta Was this translation helpful? Give feedback.
-
I think my app is currently classified as a public but unlisted app, but I'm not real sure, because most of the pages related to application management are completely broken and have been for a very long time, at least for my app. I guess I'll spend a few days dealing with that problem, too, so I don't have to deal with Amazon trying to draft me $1400 that they won't be able to lol I honestly see myself getting out of this side of the business. Sellercentral is basically trash grade, so I write tools that replace it that aren't trash grade, but I am not a high volume seller, and I guess I can see that they no longer want the sellers that are not selling millions of units. Message received loud and clear. |
Beta Was this translation helpful? Give feedback.
-
|
I think many developers will reviewing their product offerings and shifting effort into other platforms. I predict Amazon will realise this was a bad idea in a year or two. |
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.
-
|
These are the sorts of things where someone is intentionally eliminating a specific classification of user/developer. Same things Twitter and Reddit and others have done with their APIs. Yeah the "these have maintenance costs" thing is ridiculous -- SellerCentral uses all of this, or some equivalent of it. On the bright side, if I do continue, I guess I only have to dev the features I want/need, I don't have to worry about the potential users I will never have to sell it to now lol Or sell the application directly to other people to run on their own accounts. |
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.
-
|
Are you referring to sellers using their own private developer keys? Every store needs to apply for and activate private developer keys; it's not that it's impossible, but it's probably the only option available to them. |
Beta Was this translation helpful? Give feedback.
-
Exactly. The seller pays a licence fee to the ex-developer and uses their private keys to operate it. |
Beta Was this translation helpful? Give feedback.
-
|
We are also exploring this feasibility. However, there's a problem: private developer PII (Portable Internet Application) will trigger an Amazon audit, which seems problematic for many sellers. Most sellers lack the capacity for account maintenance, and they might resist if they have to pay extra. From what we understand, the top SaaS ERP providers haven't yet announced any additional fees. Rumors suggest these service providers are negotiating with the Amazon SP-API team to buy out unlimited API calls for tens or even hundreds of thousands of dollars per month. This situation will impact most small and medium-sized ERP service providers. When resources are monopolized, ERP price increases are inevitable. |
Beta Was this translation helpful? Give feedback.
-
|
You're right, the audit is a potential problem and no one knows what Amazon's goal really is. i.e. Do they want shot of small developers? If developers charged more for Amazon it wouldn't be good for Amazon, but then we'd eventually just be trampled on. I find eBay are very easy to work with. Night and day. |
Beta Was this translation helpful? Give feedback.
-
|
Amazon are onto this https://sellercentral.amazon.com/mws/static/agreement?locale=en_GB API Developer Terms |
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.
-
|
Yeah, Amazon are going to need a new department to manage the charging disputes as it's easy to count calls and failures comparing the numbers with Amazon's bill. |
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