1. Why “either-or” is the wrong frame

Nearly every comparison article on this topic stages the official API and scraping as two opponents and produces a pros-and-cons table. It reads well and it misleads the decision.

The reason is that their data domains barely overlap. The SP-API is scoped strictly to your seller account: orders, inventory, fulfillment, your own listings, your own advertising performance. It answers “how is my business doing right now”. Public page collection returns product information, search results, reviews, best seller ranks and sponsored placements. It answers “how is the market doing right now”.

Those are different questions. You would not use the official API to check a competitor’s price, because it is not designed to expose that data. You would not scrape your own orders, because they sit behind login and are account-private.

So the useful question is not “which one” but “which of my questions are account-domain and which are market-domain”. The former goes through the official interface, the latter through public data. For most teams the answer is: both.

2. The authorization boundary: where each route gets its legitimacy

Compliance discussions tend to slide into an unanswerable “which is more legal”. The two routes draw legitimacy from entirely different sources, and what determines compliance is what you collect, not which method you use.

Official SP-API: contractual authorization

The SP-API is legitimate through an explicit agreement chain: developer registration, seller authorization via Login with Amazon, and role-based access granting the minimum necessary scope. Operations touching personally identifiable information require a separate restricted role and review. What you can violate is the developer agreement and data protection policy, and the consequence is revoked authorization.

The boundary is clear but narrow: only the data a seller has actively authorized your application to access. You cannot see other sellers’ orders, and you cannot see market-level ranking data.

Public page collection: terms and robots directives

Collecting public pages is not authorized by contract. It sits under the platform’s conditions of use, robots directives and rate limits. There is no signed agreement, but that is not the same as prohibition — publicly visible, non-personal page information can generally be collected, which is long-standing industry practice.

Risk rises with three specific things, and these are what actually deserve attention:

• Login-gated content — anything visible only after signing in has clearly crossed the “public” line.
• Personal data — buyer names, addresses and contact details are personal data governed by data protection law and should not be collected.
• Aggressive request rates — traffic heavy enough to affect site operation shifts the activity from reading public information to interfering with a service.

The one-line test: is the data publicly visible and non-personal? The method is irrelevant. Misusing PII through the official interface is still a violation; collecting a fully public page can still be compliant.

3. Public vs private: a boundary that matters more than the method

Draw the line by data domain rather than by collection method and the architecture becomes obvious.

Note the last column: the route follows from the nature of the data, not from preference. This is also why “can we just use the official API” is answered no in most teams — you need market data, and it is outside the official interface’s authorization scope.

A public page field sample

Here is what structured public page data typically looks like. Every field below is public and non-personal:

{
  "asin": "B0CXYZ1234",
  "marketplace": "amazon.com",
  "title": "Stainless Steel Insulated Water Bottle, 32 oz",
  "price": { "current": 34.99, "currency": "USD", "listPrice": 44.99 },
  "rating": { "average": 4.6, "count": 12847 },
  "bsr": [ { "category": "Sports & Outdoors", "rank": 128 } ],
  "availability": "In Stock",
  "sponsored": false,
  "fetchedAt": "2026-08-30T10:22:41Z"
}

There is no buyer information here and nothing requiring seller authorization. That is the compliance basis for public collection. By contrast, orders, buyer addresses and settlement detail never appear on public pages — they are only reachable through the SP-API after explicit seller authorization.

4. Coverage, rate limits and maintenance cost, compared on one task

Since the two are complementary, a fair side-by-side only makes sense on the same task. The comparison below is scoped to one question: obtaining public market data such as products and search results.

What SP-API throttling actually costs you

The SP-API uses a token bucket model: each operation has its own request rate and quota, and quota refills continuously at that rate. For some operations the initial quota and refill rate also scale with seller business volume. Three practical consequences:

• High-frequency polling of orders or inventory requires queueing with backoff, or you get throttled errors.
• Quotas are independent per operation, so each needs its own model — a single “total call volume” estimate will be wrong.
• Concrete values change as Amazon adjusts them. Verify current figures in the official documentation rather than reusing numbers from older docs.

This is routinely overlooked: even though the official interface is free, throttling converts into engineering complexity. If you need high-frequency, high-volume data, the rate limit is itself a design workload.

The real cost of self-built scraping

The cost is not servers. It is four recurring categories: anti-bot maintenance as detection rules change, rendering as more content depends on JavaScript, parsing and field drift requiring selector rewrites plus history backfill after every redesign, and incident debugging.

The conversion is straightforward. A team spending 0.3 engineer-days a month maintaining a collection pipeline, priced at real internal cost, usually exceeds the annual bill for a mid-sized API volume over a year — and that cost recurs every quarter.

5. Hybrid architecture: running both routes together

Since the routes are complementary, the production architecture should accommodate both and converge them at the ingestion layer. A recommended shape:

[Authorized domain · SP-API]        [Public domain · collection]
  Orders / inventory / fulfillment    Products / search / reviews
  Settlements / own ad performance    Ranks / categories / ads
        ↓                                      ↓
  Auth and token management            Fetch · render · parse · anti-bot
        ↓                                      ↓
        └──────────→ [Unified ingestion] ←─────┘
                     field mapping · type validation
                     failure classification · quality gates
                              ↓
              Business systems / data pipelines / AI agents

Three design points:

The unified ingestion layer is not optional. Both routes map into one internal model there, with strict type validation. When either side changes, errors are caught at that layer instead of propagating downstream.

Classify failures separately. Throttling errors from the official interface, blocked pages from public collection, and missing fields common to both should be three separate counters with separate alerts. Merged into one error log, you cannot tell whether the problem is quota, anti-bot or coverage.

Do not substitute one route for the other. The most common design mistake is trying to infer your own orders from public collection — impossible and inappropriate — or estimating market share from the official interface, which is out of scope. Keep each route inside its own data domain.

6. Compliance checklist

Before going live, confirm each item:

Rule of thumb: public and non-personal → collectable; login-gated or containing personal information → must go through the authorized interface; when unsure, default to the stricter side.

7. Decision table: match your task to a route

Skip the route debate and read your task off the table.

The last row deserves emphasis: if your requirements stop at your own operations, do not add public collection. That is not conservatism, it is avoiding compliance and maintenance cost for coverage you will never use.

References: Amazon Selling Partner API official documentation (authorization, roles and throttling model), Amazon conditions of use and robots notices, and Pangolinfo published service metrics.