Short answer: Amazon SP-API authorization lets you give a software tool access to your seller data without handing over your Seller Central password. You approve the app on an Amazon consent page, Amazon issues the app a token tied to specific permissions, and you can disable that access at any time from Manage Your Apps in Seller Central.
If a tool or service provider asks for your login and password instead, treat that as a warning sign. This guide explains how the authorization flow works and what to check before you approve any app.
What the Selling Partner API is
Amazon describes its Selling Partner API (SP-API) as "a REST-based API that helps sellers and vendors access their data on orders, shipments, payments, inventory, and other business information." Order management tools, repricers, inventory systems and warehouse platforms use it to read and update your seller data.
The key point for sellers is how access is granted. Amazon uses Login with Amazon (LWA), which it describes as "Amazon's implementation of OAuth 2.0." OAuth is a standard way for one service to get limited, revocable access to your account on another, without learning your password.
How the authorization flow works, step by step
Amazon's developer documentation describes the flow for public applications. From the seller's side, it looks like this:
- You start the connection. You click an authorize button on the app's website, or find the app in the Selling Partner Appstore and choose to authorize it.
- You sign in to Amazon, not to the app. You enter your credentials on Amazon's own page. The app never sees them.
- You review a consent page. Amazon shows which app is asking and what it wants to access. You approve or cancel.
- Amazon gives the app a short-lived code. Amazon notes that "authorization codes expire after five minutes," so the app must exchange it straight away.
- The app receives tokens. The code is exchanged for a refresh token. The app uses the refresh token to get access tokens, which Amazon says "are short-lived (typically one hour)."
- The app calls the API on your behalf, within the permissions you approved.
Authorization does not last forever without review. Amazon's documentation states: "The selling partner must reauthorize your public application every 365 days, or anytime you add a role to your application." Re-authorization happens from Manage Your Apps in Seller Central.
Why sharing your Seller Central password is the wrong model
Amazon's own forum staff are direct about this. An Amazon staff guide to user permissions says: "Don't share your password with other people." The same guide adds: "Don't add external third-party service providers or developers as users. You can add third-party service providers as partners by going to the 'Authorized Partners' tab under Global Account."
For your own employees, Amazon's guidance is to use User Permissions and to "grant the minimum permissions required for them to do their job." For software, the equivalent is SP-API authorization.
A shared password creates problems that OAuth avoids:
- No separation. Anyone with your password can do anything you can, including changing bank details.
- No clean exit. To remove access, you must change your password and update every person and tool that used it.
- No audit trail. When several people use one login, you cannot tell who did what.
- More exposure. Passwords stored in chats, spreadsheets or scripts can leak.
Password sharing vs SP-API authorization
| Question | Sharing your password | SP-API authorization |
|---|---|---|
| Does the app or provider know your password? | Yes | No; you sign in on Amazon's page |
| What can it access? | Everything you can | Only what the app's approved roles allow |
| How do you remove access? | Change your password everywhere | Disable authorization in Manage Your Apps |
| Does access expire? | Not until you change the password | Re-authorization is required every 365 days |
| Who is accountable for data protection? | Unclear | The developer must follow Amazon's data protection rules |
| Can you tell who did what? | Not easily | Each authorized app is listed separately |
Roles: what an app can and cannot see
Approval on the consent page is not a blank cheque. Amazon explains that "roles are the mechanism by which the Selling Partner API (SP-API) determines whether a developer or application has access to an operation or resource." A developer must request and qualify for each role, and calls outside those roles are refused.
Some roles are marked restricted. Amazon says "restricted means that the role requires sensitive information, which might include personally identifiable information (PII)." Examples include direct-to-consumer shipping and tax invoicing. For these roles, Amazon asks developers for additional information about their data use and security controls before approving them.
What this means for you: an app that ships orders for you may legitimately need buyer names and addresses. An app that only reports sales should not. If the permissions seem broader than the job, ask why.
What Amazon requires of developers
Developers who access SP-API agree to Amazon's Data Protection Policy. Among other things, it requires them to:
- encrypt information in transit "with secure protocols such as TLS 1.2 or higher" over public networks;
- "encrypt all PII at rest using at least AES-128 or RSA with 2048-bit key size or higher";
- keep programmatic credentials, including API keys, "encrypted at rest, accessible only to authorized personnel, and rotated at least once every twelve (12) months";
- avoid hardcoding sensitive credentials such as keys or passwords in code;
- retain PII "for no longer than 30 days after order delivery," and only for permitted purposes such as fulfilling orders and tax;
- notify Amazon within 24 hours of detecting a security incident.
You cannot audit a developer yourself, but you can ask how they meet these requirements and how they store your tokens.
A checklist before you authorize any app
Run through these questions before you click approve:
- Does it use the official flow? The connection should send you to an Amazon sign-in and consent page. Never type your Amazon password into a third-party form.
- Does it ask for a password anyway? If a provider wants your login "to set things up," decline and ask for SP-API authorization or Authorized Partner access instead.
- Are the permissions proportionate? Shipping tools may need buyer addresses; reporting tools usually do not.
- How are tokens stored? Look for a clear statement that tokens are encrypted at rest.
- How do you disconnect? You should be able to disable access from Seller Central and, ideally, from inside the app.
- Who can see your data inside the tool? Check for role-based access, so a packer cannot see supplier costs and one client cannot see another's orders.
How to review, re-authorize or revoke access
Amazon's documentation gives the paths:
- Revoke: in Seller Central, go to Apps and Services, then Manage Your Apps. Find the application, choose Disable authorization, then confirm. Amazon notes the app is disabled "but remains viewable on the Manage Your Apps page."
- Re-authorize: sign in to Seller Central, go to Manage Your Apps, find the application and choose Re-Authorize.
A good habit is to review Manage Your Apps every quarter and disable anything you no longer use. Do the same for Authorized Partners and user permissions, especially when a team member or agency relationship ends.
How HutsyBoard connects to Amazon
We built HutsyBoard by ECOMHUTSY around this model. HutsyBoard is a marketplace-to-warehouse platform for Amazon FBM sellers, and its Amazon connection follows the rules above:
- SP-API OAuth connect. You authorize HutsyBoard through Amazon's consent flow. No passwords are shared.
- Encrypted tokens. Tokens are encrypted at rest.
- Disconnect at any time. You stay in control of the connection.
- Multi-tenant roles. Companies, branches and warehouses stay separated, and each person sees only the work their role allows.
Once connected, HutsyBoard runs the FBM loop: orders and shortfall, purchasing with supplier proof, QR receiving, owned and shared inventory, pick, pack and ship, and profit. Read the Amazon FBM order-to-ship workflow for how that loop works, see HutsyBoard for the product overview, or read about ECOMHUTSY's security approach. A trial is available at hutsyboard.com.
ECOMHUTSY has worked in e-commerce operations since 2016 and has a team of 100+ e-commerce professionals across offices in Multan, Dubai and Westland, MI. Secure authorization protects your account access; it does not by itself promise any sales or account-health outcome.
Frequently asked questions
Is it safe to connect a third-party tool to Seller Central?
It is safer when the tool uses SP-API authorization. You approve the app on Amazon's consent page, the app never sees your password, and you can disable it from Manage Your Apps. Still check what permissions it asks for and how it stores tokens.
Why does Amazon ask me to re-authorize an app?
Amazon requires sellers to re-authorize public applications every 365 days, and whenever the app adds a role. It is a periodic check that you still want the app to have access.
What happens when I disable an app's authorization?
The app loses access to your data through SP-API. Amazon says the app is disabled but remains visible on the Manage Your Apps page, so you have a record of it.
Should I add an agency as a user on my account?
Amazon's staff guidance says not to add external service providers or developers as users. Add them as Authorized Partners instead, and connect their software through SP-API authorization.
Connect your tools the right way
Want to review how your tools and service providers access your Amazon account, or see how an SP-API connection works in practice? Talk to an ECOMHUTSY operator.
Amazon's developer requirements and Seller Central menus change. This article reflects publicly available Amazon information as of October 2026. Always check Amazon's documentation for current steps.
Sources
- Amazon Developer Docs, What is the Selling Partner API?: https://developer-docs.amazon/sp-api/docs/what-is-the-selling-partner-api
- Amazon Developer Docs, Authorize public applications (LWA, OAuth 2.0, code and token lifetimes, 365-day re-authorization): https://developer-docs.amazon/sp-api/docs/authorize-public-applications
- Amazon Developer Docs, Reauthorize applications: https://developer-docs.amazon/sp-api/docs/renew-authorizations
- Amazon Developer Docs, Revoke authorizations: https://developer-docs.amazon/sp-api/docs/revoke-authorizations
- Amazon Developer Docs, Roles in the Selling Partner API: https://developer-docs.amazon/sp-api/docs/roles-in-the-selling-partner-api
- Amazon, Data Protection Policy: https://sellercentral.amazon.com/mws/static/policy?documentType=DPP&locale=en_US
- Amazon Seller Forums, Amazon staff guide to seller account user permissions: https://sellercentral.amazon.com/seller-forums/discussions/t/c1d879bd-456f-4cde-a616-78062dda2498
