Amazon Solution Provider Portal (SPP) Setup: Full Guide for Developers (2026)

There are two ways to use the SP-API, and people constantly start down the wrong one.

1. Self-authorization — you only ever call the API for your own seller account. You do this straight from Seller Central → Develop Apps, no verification queue. That's covered in How to Get Amazon SP-API Access.
2. Building an app other sellers authorize — an agency tool, a SaaS, a client dashboard. That's a public/shared application, and it requires a verified developer profile in the Solution Provider Portal (SPP).

If you're building anything that more than one Amazon account will connect to, you're on the SPP path. This guide walks the whole thing end to end.

Sign in to Seller Central (or Vendor Central) and open the developer registration flow under Apps & Services → Develop Apps. Before Amazon lets you create a shared app, it asks you to register as a developer and complete a profile.

You'll provide:

• Business and contact details
• Acceptance of the Amazon Developer Agreement, Acceptable Use Policy, and Data Protection Policy
• A security & data-handling questionnaire — how you store data, who can access it, how you protect PII, and whether you'll request restricted (PII) roles

Once your developer profile is active, create the app from Develop Apps → Add new app client. You'll provide:

• App name — what sellers see on the consent screen
• API type → SP-API
• Roles — the data your app can touch (next step)
• OAuth Login URI and Redirect URI — the authorization workflow (Step 5)

New apps start in a Draft state. A draft app fully works for your own account and for a small number of test sellers you invite — enough to build and test the entire integration before you ever go public.

Roles map to endpoints. Request only what your app actually uses — least privilege gets approved faster and is easier to defend in the security review.

• Common roles: Orders, Inventory & Order Tracking, Pricing, Product Listing, Reports, Finance & Accounting
• Restricted (PII) roles: Tax Invoicing, Direct-to-Consumer Shipping, Tax Remittance — these unlock buyer name/address and trigger an additional questionnaire

After the app is created, open it and reveal the Login with Amazon (LWA) credentials:

• Client ID — amzn1.application-oa2-client.xxxx
• Client Secret

These are the identity of your application. Store the secret somewhere safe (a secrets manager, not source control) — you'll use both to exchange authorization codes for refresh tokens.

A shared app authorizes sellers over OAuth, so it needs two HTTPS endpoints configured on the app:

• OAuth Login URI — the page on your site where the seller starts consent
• Redirect URI — where Amazon sends the seller back, with a spapi_oauth_code in the query string

With the URIs set, a seller can connect. Two entry points:

• Amazon Marketplace Appstore — a public listing sellers install from
• Website workflow — you host a “Connect your Amazon account” link (great for private/self-serve B2B tools)

The seller consents → Amazon redirects to your Redirect URI with an spapi_oauth_code → you exchange it for a long-lived refresh token bound to that seller:

curl -X POST https://api.amazon.com/auth/o2/token \
  -d grant_type=authorization_code \
  -d code=SPAPI_OAUTH_CODE \
  -d client_id=YOUR_LWA_CLIENT_ID \
  -d client_secret=YOUR_LWA_CLIENT_SECRET

Store that refresh token against the seller — it's what your backend uses to mint short-lived access tokens for their account from then on.

A Draft app is enough for your own account plus invited test sellers. To onboard arbitrary sellers publicly, you submit the app for listing/publishing and it goes through Amazon review. Plenty of B2B tools skip the public Appstore entirely and stay “private,” simply sharing their authorization link with clients.

• Verification stuck “pending”: incomplete business info or a thin data-handling answer. Fill in specifics and respond to Amazon's follow-ups quickly.
• “Application not authorized for role”: you added a role after the seller authorized. They must re-authorize to get a token with the new scope.
• Redirect fails / no code returned: Redirect URI doesn't exactly match what's configured on the app.
• Wrong region: using the NA endpoints for an EU seller (or vice-versa). Match the region to the seller's marketplace.

Do I need SPP if I only automate my own account?

No. Use Seller Central → Develop Apps and self-authorize — no developer registration, no review. See the SP-API access guide. SPP is only for apps that other sellers connect to.

How long does developer verification take?

Anywhere from a couple of days to a few weeks depending on the roles you request and how complete your answers are. Restricted/PII roles take the longest — apply well before launch.

Is SPP the same thing as “Develop Apps”?

Develop Apps is the screen where you create and manage app clients. The Solution Provider Portal is the broader developer program around it — registration, verification, listing, and the multi-seller OAuth workflow. For a shared app you touch both.

What's the difference between a Draft and a published app?

Draft works for your own account and invited test sellers — ideal for building. Published (listed) apps can be authorized by any seller, after Amazon reviews the listing. Many private tools never publish; they just share the authorization link.