"Amazon API" points at three different things, and they do not overlap. Choosing wrong does not cost you speed — it costs you the discovery, halfway in, that the data you need was never on that road.
The dividing line is whose data it is
| Official SP-API | Third-party data API | Your own scraping | |
|---|---|---|---|
| Whose data | Only your own store's | Public marketplace data | Whatever is on the page |
| Typical fields | Orders, inventory, settlements, ad reports | Competitors, keywords, markets, ranks | What the other two miss |
| Authorisation | Seller account grant | API key | None |
| Can it see competitors | No | Yes, as estimates | Yes, if you maintain it |
The "No" in that table is the important cell.
The common misjudgement: SP-API for competitor data
SP-API is the Selling Partner API. It serves selling partners and their authorised business data — your own orders, inventory, settlements and advertising reports. Exact, authoritative, current.
It gives you nothing about a competitor. No order volume, no conversion rate, no ad spend. That is not a permissions gap; it is not in scope by design.
The mistake is easy to make because "official API" sounds like it should have everything. The real split is: the official API gives you your own real data, third-party endpoints give you other people's estimated data. They are complements, not alternatives.
Which is why this combination is the usual real-world setup:
Take your own ACOS and order volume from SP-API (exact), take which keywords a competitor ranks under from a third-party endpoint (estimated), and put them together to answer whether to bid higher on that keyword.
Neither side answers that alone.
What a third-party data API covers
The public half: products, categories, keywords, traffic, ranks, reviews.
API catalogue46 endpoints grouped by products, keywords, markets, traffic and trademarks, with what each returnsThree things to establish before committing to this route:
1. Which numbers are estimates. Sales and revenue always are — the marketplace does not publish them. Price, BSR and ratings count are facts. An endpoint that does not distinguish the two leaves you unable to judge how hard a conclusion you can draw.
2. Freshness and timestamps. Data without a timestamp cannot support a trend claim. You need to know when it was measured.
3. Marketplace coverage. Supporting the US implies nothing about the marketplace you actually sell in. Verify it separately.
When scraping is still the answer
Fields neither of the first two reach do exist — a particular page module, a badge that only appears under certain conditions, a category so new no data source covers it yet.
Before taking that road, cost it honestly. Getting it working is day one; after that it is anti-bot measures, page redesigns, compliance boundaries and the person who maintains it leaving. The hardest of those to budget is the second: you cannot predict when the platform changes its markup, or whether the change lands on the structure you depend on.
A simple test: is this field something only you need? If it is a common requirement, an endpoint probably covers it already and you are rebuilding a wheel. If it genuinely only matters to your business, scraping earns its place.
This post does not cover evading detection.
The order to decide in
Two questions usually settle it.
First: do I want my own data or someone else's?
- Your own → SP-API, done
- Someone else's → continue
Second: is the field publicly visible?
- Yes → third-party endpoint, check it is in the coverage
- No → it may not be obtainable at all (below)
Three things none of the three routes return
Worth listing separately, because it means some requirements need rephrasing rather than re-sourcing.
A competitor's backend search term report. Authorised seller-account data, visible only to that account.
A competitor's real order volume. Not published. Every monthly sales figure is derived from BSR.
Buyer identity. Not available, and the wrong direction to pursue.
If a plan depends on one of these, the plan needs changing, not the data source.
What each route costs to run
| SP-API | Third-party API | Scraping | |
|---|---|---|---|
| Time to start | Application and approval | Create a key | Depends on the target |
| Upfront | Engineering time | Engineering time plus call costs | Engineering time |
| Ongoing | Maintaining the grant | Call costs | Anti-bot work and redesign chasing |
| Least predictable | Approval timeline | Usage growth | Platform changes |
The third-party column's ongoing cost is budgetable, by call volume. The scraping column's is not. That is the most practical difference between them.
If you take the third-party route, The complete Amazon data API guide breaks the 46 endpoints down by the job each does and how to chain them. This post is about the question before that one: which of the three roads to take.
Questions
Does MWS still work? MWS is retired; SP-API is the supported path. If you maintain an MWS integration, migrating is required rather than optional.
Can one API do everything? No. The "whose data" table is the reason — your own data and other people's come from different authorisation models, and no single endpoint spans both.
Is third-party data accurate? It depends on the field. Price, BSR and ratings count are publicly visible and accurate. Sales and revenue are estimates whose accuracy depends on the model and the category. Ask about the two separately rather than about accuracy in general.
Can I validate with a free option first? You can, as long as you validate with real workload rather than a demo. Limits usually surface only after a full pass through the workflow.