I have a hard time imagining what kind of "side project" would be making use of the Amazon Selling Partner API. It all revolves around managing listings and sales through the Amazon storefront - if you've got a use case for that, it's probably for something serious.
These players will try to bypass the API limitations by scraping the customer website if they have to, but Amazon may engage in a cat n mouse game with them rather than just throttling abusively stupid clients.
I'm not sure what kind of data is vended through this API, but it seems like if this is data on products that amazon.com sells, won't people simply resort to scraping using residential proxies, mobile networks, etc. which are harder to mitigate?
It’s interesting that only GET calls are metered. Is this a common thing to do?
I wonder if this is also being done to limit marketplace data being scraped with the API or limit how this data gets used by limiting low margin business models. Increasing the fees will have these effects.
I've been noticing this happen more lately. Intuit QuickBooks did this exact same thing for GET calls this year as well.
My theory is they see POST/PUT calls as adding value and are actions that customer need to perform and help the platform (adding products, inventory, etc). But GET calls they see as leaching off them and not core requirements.
The huge gap in this theory are things like Seller Fulfilled orders which you have to GET, but for Amazon they have always pushed hard for Amazon Fulfilled instead.
In the end I think this is all mostly to keep things/control in-house as much as possible. Some apps will shut down, others will pass the cost along the sellers. Sellers always lose.
The focus on charging for GETs is unfortunate given that in my (very outdated) experience developing against MWS, many of the APIs are of the “POST to receive a token that you GET-poll on” variety.
So much spam would go away if we just charged $1 per 5000 emails. Normal humans would be fine. Mailing lists would need charge, but it would be minimal for most useful mailing lists.
These are pretty steep API fees for a company already taking a hefty cut on every order flowing through this API.
Kinda feels like they gave up on getting devs to write well-behaved apps by asking nicely, so now they're charging them. :shrug:
$1/20k gets shouldn't be a big deal?
And an annual $1400 which effectively kills side projects.
I have a hard time imagining what kind of "side project" would be making use of the Amazon Selling Partner API. It all revolves around managing listings and sales through the Amazon storefront - if you've got a use case for that, it's probably for something serious.
This is true of no end of APIs. It's another cost that would be difficult to be borne by a bootstrapped startup still finding PMF and early traction.
I hope this does not affect Camelcamelcamel or Idealo, because if not we lose the power to get real visibility over real value of items.
These players will try to bypass the API limitations by scraping the customer website if they have to, but Amazon may engage in a cat n mouse game with them rather than just throttling abusively stupid clients.
Any chance this is related to Agentic Commerce, and Amazon wanting to protect their moat?
Uf that also means that the business api is affected? to pull invoices and stuff. https://developer-docs.amazon.com/amazon-business/docs/downl... not sure if that will be paid as well
I'm not sure what kind of data is vended through this API, but it seems like if this is data on products that amazon.com sells, won't people simply resort to scraping using residential proxies, mobile networks, etc. which are harder to mitigate?
It’s interesting that only GET calls are metered. Is this a common thing to do?
I wonder if this is also being done to limit marketplace data being scraped with the API or limit how this data gets used by limiting low margin business models. Increasing the fees will have these effects.
I've been noticing this happen more lately. Intuit QuickBooks did this exact same thing for GET calls this year as well.
My theory is they see POST/PUT calls as adding value and are actions that customer need to perform and help the platform (adding products, inventory, etc). But GET calls they see as leaching off them and not core requirements.
The huge gap in this theory are things like Seller Fulfilled orders which you have to GET, but for Amazon they have always pushed hard for Amazon Fulfilled instead.
In the end I think this is all mostly to keep things/control in-house as much as possible. Some apps will shut down, others will pass the cost along the sellers. Sellers always lose.
The focus on charging for GETs is unfortunate given that in my (very outdated) experience developing against MWS, many of the APIs are of the “POST to receive a token that you GET-poll on” variety.
Only the GET requests are metered. An anti-bot/anti-AI scraper measure?
They probably want to remove pricing transparency.
Maybe some kind of anti-fraud measure too?
So much spam would go away if we just charged $1 per 5000 emails. Normal humans would be fine. Mailing lists would need charge, but it would be minimal for most useful mailing lists.
Maybe Amazon is going after some fraud?
So they charge the sellers and also the API users? Isn’t that double dipping?
Oh no! Poor little Amazon hasn't found a way to triple dip ... yet?
[dead]