Amazon SP-API Explained: What Connected Apps Access

Quick answer: Amazon's SP-API connects seller software through official OAuth authorization on Amazon's own domain. A legitimate connection should never ask for your Seller Central password.

Connecting software to Seller Central can feel uncomfortable. The app asks for authorization, Amazon shows a permissions screen, and the seller is expected to decide in about four seconds whether the connection is safe.

The right question isn't "does this app connect to Amazon?" Almost every useful seller tool does. The better questions are: how does it connect, what data does it request, why does it need that, and how can access be revoked later.

What SP-API actually is

SP-API stands for Selling Partner API. It's Amazon's official interface for approved applications to exchange data with Seller Central systems. Depending on the permissions granted, an app may read orders, inventory, reports, listings, finances, or advertising data, and may perform specific permitted actions like sending an official review request.

The API lets software automate work that would otherwise mean manual exports, repeated clicks, or a spreadsheet somebody has to remember to update.

OAuth means you should never share your password

A legitimate authorization flow sends the seller to Amazon to approve access, on Amazon's own domain. The third-party app should never need, or ask for, the seller's Seller Central password.

After approval, Amazon issues tokens that let the app perform the authorized work. The seller can revoke that authorization from Seller Central at any time. That's a fundamentally different arrangement from handing a virtual assistant or an unfamiliar website the master login.

What data an analytics app actually needs

A sales dashboard needs order and sales data. An inventory tool needs FBA inventory and product identifiers. A review-request tool needs enough order and delivery information to determine eligibility and call the official Request a Review workflow. An advertising dashboard needs authorized advertising data. Nothing more.

The operating principle is data minimization: the app should request what its features require, not every permission available. Its privacy policy should say plainly what categories of data it touches, where it's stored, how it's secured, and how it's deleted.

Restricted data deserves extra scrutiny

Some Amazon data is more sensitive than ordinary performance metrics. Personally identifiable information and customer-related data fall under Amazon's data protection requirements, and providers handling it should be able to explain their controls around encryption, access, retention, and incident response without hand-waving.

A seller doesn't need to become a security engineer to ask two questions: why does this app need customer-related data, and how long does it keep it. A vague answer to either one is the actual warning sign, not the existence of the connection itself.

A seven-point check before connecting anything

1. Confirm the authorization happens on an Amazon domain, through the official OAuth flow, not a form asking for your Seller Central login.
2. Read the permission screen and compare it against the features the app actually promises.
3. Read the privacy policy, specifically the sections on storage, sharing, retention, and deletion.
4. Check that the company identifies itself and provides a real support channel.
5. Ask whether data is encrypted in transit and at rest.
6. Confirm access can be revoked, and that cancelling the account actually removes stored data per the stated policy.
7. Use a unique password on the app account and turn on multi-factor authentication if it's offered.

What a connected app should never ask you to do

It should never ask for your Seller Central password as part of a normal SP-API connection. It should never tell you to work around Amazon's own security controls. It shouldn't hide who operates the service, and it shouldn't claim unlimited access without explaining what permissions that actually covers.

Be cautious specifically with browser extensions that perform bulk actions by simulating clicks rather than calling the API directly. Some are legitimate, but the security and compliance model is genuinely different from a server-side integration authorized through Amazon's own OAuth flow. It's worth knowing which one you're actually using.

Revoking access is the easy part, deletion is the part to verify

Amazon lets sellers manage authorized applications from within Seller Central; the exact navigation shifts slightly with interface updates, but the account's app-authorization area will show every connected developer and application.

Revoking access stops future API calls immediately. It doesn't, on its own, prove that previously stored data has been deleted. For anything that matters, follow up with the provider's own account-deletion process and keep the confirmation.

A common, low-drama failure mode here is pure governance drift: a team tries three analytics tools in one month, one person authorizes each, nobody writes down who owns which connection or why, and six months later two unused apps still have live access to the account. Nothing malicious happens. It's just an open door nobody remembers leaving open. A simple register, app name, owner, purpose, permissions, date connected, review date, checked quarterly, closes most of that gap without any extra software.

---

This is exactly how EcomSanity connects: Amazon's official SP-API OAuth authorization, nothing that ever asks for a Seller Central password, and access you can revoke from Amazon's own settings at any time. The privacy policy spells out what data categories that connection actually touches. For a walkthrough of one specific permitted action, sending the official review request, see Amazon review request automation.