API (Application Programming Interface) - Amazon Glossary

Amazon API (Application Programming Interface) is the set of official interfaces that let external software exchange data with Amazon directly, without a human clicking through Seller Central. Instead of downloading reports and editing spreadsheets, a connected system can pull orders, inventory, financial events, and advertising data in near real time, and push changes back: prices, stock levels, listing content, shipment confirmations.

The confusion starts with the fact that there is no single "Amazon API." Amazon operates several separate API families, each with its own purpose, access model, and documentation. A seller who wants automation, or is choosing software that promises it, should understand which interface actually does what.

The Main Types of Amazon APIs

SP-API (Selling Partner API). The SP-API is the core interface for anyone selling on Amazon today. Launched in October 2020, it is a suite of JSON-based REST APIs covering nearly every part of a seller's operations, organized into functional sections: Orders, Reports, Feeds, Listings, Catalog Items, Finances, FBA Inventory and Inbound, Notifications, and analytics endpoints such as Data Kiosk and Brand Analytics reports. When a modern seller tool advertises an "official Amazon integration," this is almost always what it means.

How a business uses SP-API depends heavily on its fulfillment model. Sellers on Fulfillment by Amazon (FBA) lean on the inventory and finance sections: tracking inbound shipments, auditing the FBA inventory ledger against their own records, and identifying lost or damaged units that Amazon owes money for. Sellers on Fulfillment by Merchant (FBM) work mostly with the order and shipping sections: pulling new orders, buying labels, and confirming shipments with valid tracking. Those confirmations feed the performance metrics (on-time delivery, valid tracking rate) that determine account health and Buy Box eligibility, so for FBM sellers the API is not just a convenience but part of staying competitive.

Amazon MWS (Marketplace Web Service). MWS was the predecessor of SP-API and served sellers from 2009 until its full shutdown on March 31, 2024. It was built on an older XML-based architecture, with signature-based authentication instead of OAuth, and no sandbox for testing. Amazon deprecated it in stages: public third-party applications had to migrate by the end of 2022, private integrations followed, and today MWS credentials no longer return data. The term still appears in older articles and legacy software documentation, which is worth knowing so you can recognize outdated material. Any integration you build or buy now must run on SP-API.

Amazon Ads API. Advertising lives in a completely separate system with its own registration, tokens, and rate limits. The Ads API manages Sponsored Products, Sponsored Brands, and Sponsored Display campaigns programmatically: creating campaigns, adjusting bids and budgets, pulling performance reports down to the keyword and search-term level. It also includes Amazon Marketing Stream for near real-time campaign metrics. This is the interface behind every PPC automation tool on the market. A common misunderstanding is expecting advertising data from an SP-API connection; a tool needs separate Ads API authorization to touch your campaigns.

Product Advertising API (PA-API). Despite the similar name, PA-API has nothing to do with running ads. It is the interface for the Amazon Associates affiliate program, used by content sites to pull public product data (titles, images, prices, availability) and generate affiliate links. Sellers rarely need it, but it is frequently confused with the Ads API, so it deserves a mention.

One more disambiguation: AWS (Amazon Web Services) APIs are cloud infrastructure and have nothing to do with marketplace selling, even though early SP-API versions borrowed AWS request signing. That requirement was dropped, and SP-API today authorizes purely through Login with Amazon (OAuth 2.0).

How Access Works and What to Watch For

SP-API access comes in two forms. You can self-authorize a private application through your own developer profile in Seller Central, or grant access to a third-party application from Amazon's Appstore via OAuth consent. In both cases authorization produces a long-lived refresh token that software exchanges for short-lived access tokens. Sensitive customer data (names, addresses) additionally requires Restricted Data Tokens, a mechanism Amazon added to keep PII out of systems that don't need it.

Two practical constraints trip up self-built integrations. The first is rate limiting: every SP-API operation has a defined request quota and burst capacity under a token-bucket model, and scripts that retry aggressively on throttling errors can get their developer access suspended. The second is credential security. A refresh token stored in a plain-text config file gives anyone who obtains it the same write access your software has, including the ability to change your prices and stock levels. Store secrets in a dedicated vault and rotate them regularly.

What This Means in Practice

For most sellers the realistic question is not "how do I call the API" but "does my software use it properly." Official API connections are what separate tools that work from Amazon's actual data from tools that scrape public pages. SoldScope, for example, pulls Brand Registry metrics such as Search Frequency Rank and click share through authorized SP-API access, uses the same connection to scan inventory ledgers for its Reimbursement Service, and feeds that data into the Listing Builder and Rank Tracker so listing changes and their ranking impact are tracked without manual exports. Whatever tools you choose, checking that they run on authorized API access rather than scraping is one of the simplest quality filters available.