It's a common misconception that Amazon has "an API." In practice, sellers and agencies typically integrate with two separate systems: the Selling Partner API (SP-API), covering orders, inventory, catalog, pricing, and finances; and the Amazon Ads API, covering Sponsored Products, Sponsored Brands, and Sponsored Display campaign management and reporting. Both authorize through Login with Amazon (LWA) refresh tokens, but the Ads API adds ClientId and Scope (profile) headers on every call, while SP-API adds Restricted Data Tokens for personal data. Rate limits and data models differ too, and most real projects need both talking to each other.
SP-API: built for operational, not analytical, access
SP-API is designed around operational actions (updating inventory, confirming shipments, managing listings) as much as reporting. Bulk data such as settlement reports, inventory snapshots, and older order history usually flows through the asynchronous Reports API: you request a report, poll for completion, then download it. Financial events are different: the Finances API (listFinancialEvents) is a synchronous, paginated call, so the challenge there is paging through date ranges and respecting rate limits, not waiting on a report. Mixing up the two patterns is an easy way to build a pipeline that misses data.
Ads API: built for campaign management and reporting
The Ads API is more straightforward once OAuth is set up, but reporting is also asynchronous: in v3 you request a report, poll until it's ready, then download the file. It applies dynamic throttling that varies by endpoint, so high-volume agencies managing many client accounts need request queuing and backoff logic, or they'll hit rate limits during their busiest reporting windows, exactly when the data matters most.
Where the two APIs need to meet
- Inventory-aware ad optimization: pausing or reducing ad spend on SKUs SP-API reports as low-stock, before budget is wasted
- True profitability reporting: combining Ads API spend with SP-API settlement and fee data for real (not gross) ROAS
- Enforcement risk detection: correlating SP-API catalog, listing and account-health signals
- Buy Box-aware bidding: adjusting bids based on Buy Box ownership pulled from SP-API pricing endpoints
We built the SP-API side of this for Protego, an enforcement-risk platform that connects to Seller Central via SP-API and continuously analyzes operational, catalog, and order-level signals alongside a rules-based risk engine on AWS.
“Amazon enforcement risk signals are fragmented across multiple Seller Central reports and APIs, making it nearly impossible for sellers or tools to identify risk early.”
From the Protego case study
Practical advice for teams starting this integration
Build retry and backoff logic from day one, not as an afterthought. Both APIs will throttle you, and a pipeline without graceful retries produces silent data gaps that are hard to detect later. Treat OAuth token storage and refresh as a first-class concern, especially if you're managing multiple seller accounts under one platform: expired or mishandled tokens are the most common cause of pipelines quietly going stale. For how the two feeds come together in one warehouse, see our guide to ETL pipelines for Amazon sellers.
Frequently asked questions
Can I get all Amazon seller data from one API?
No. Order, inventory, and financial data comes from SP-API; advertising campaign data comes from the separate Amazon Ads API. A complete data platform needs to integrate both.
Why does my SP-API integration keep hitting rate limits?
SP-API rate limits vary per endpoint and per operation. Most rate-limit issues come from not implementing exponential backoff and retry logic, or from polling report status too aggressively instead of using recommended wait intervals.
What AWS services are typically used to run this kind of pipeline?
A common, reliable pattern is Lambda for scheduled and event-driven ingestion, SQS for queuing between throttled API calls, S3 for raw data landing, and a client-owned warehouse such as Snowflake or BigQuery for the structured, query-ready layer. More on that layer in our marketing data warehouse work.