Step 6: Set up the Authorization Workflow

While the sandbox environment lets you explore the Selling Partner API (SP-API) functionality with test credentials, production applications need a complete authorization system that lets selling partners safely grant access to their data.

Choose your authorization method based on your application type:

• Public applications: Must use OAuth 2.0 through Login with Amazon (LWA). Selling partners can authorize your application through the Selling Partner Appstore or through your website.

• Private applications: You can self-authorize these applications directly from the Solution Provider Portal.

This topic describes these authorization workflows and set-up steps.

Terminology

Although you can self-authorize private applications, sellers authorize public applications through an OAuth 2.0 workflow. When you set up authorization for public applications, you assemble URIs, get tokens from the LWA authorization server, and fetch your client credentials from the Solution Provider Portal. The following sections briefly define these terms in the context of the SP-API.

Login with Amazon (LWA)

Amazon's OAuth 2.0 service that handles authorization between your application, selling partners, and the SP-API. During runtime, both public and private applications call LWA to exchange a refresh token for an access token to include in requests to the SP-API.

Log-in URI

A URI that lets selling partners log in to your website during the authorization flow, which enables you to associate the seller's Amazon authorization with their account in your system.

Authorization URI

A URI that lets selling partners authorize your application to access their data.

Redirect URI

A URI that redirects selling partners back to your website after authorization is complete.

Token

A secure digital key that represents authorization to access SP-API resources on behalf of a selling partner.

Access token

A short-lived credential that your application uses to make SP-API calls on behalf of a selling partner.

Refresh token

A long-lived credential that your application uses to get new access tokens without requiring the selling partner to re-authorize.

Client ID

An identifier issued by Amazon when you register your app in Solution Provider Portal. You use this ID to get access tokens for making API calls.

Client secret

A private key that proves your application's identity, issued by Amazon when you register your app in the Solution Provider Portal.

Application ID

A unique identifier that the Solution Provider Portal assigns to your application. You use this ID in authorization URLs when sellers authorize your application.

Authorization workflows

This section shows the three possible authorization workflows.

Selling Partner Appstore authorization workflow (public applications only)

Website authorization workflow (public applications only)

Self-authorization workflow (private applications only)

Steps to set up authorization

Learn how to set up different authorization workflows depending on whether your app is public or private.

Steps to set up the Selling Partner Appstore authorization workflow (public applications only)

The following steps explain how to set up authorization when sellers find and authorize your application through the Selling Partner Appstore. For more information, refer to Selling Partner Appstore Authorization Workflow.

1. Configure your website as follows:
   • Set the referrer-policy no-referrer HTTP header to prevent cross-site request forgery.
   • Set up regional sign-in if you support multiple regions.
2. Create a log-in URI page on your website and configure it to:
   • Accept Amazon's request with seller authentication parameters
   • Allow sellers to log into your website.
   • Associate the Amazon authorization with the correct account in your system.
   • Redirect to Amazon's callback URI with the required parameters.
3. Create a dedicated redirect URI page on your website (for example, https://www.example.com/sp-api/auth) and configure it to:
   • Receive authorization responses from Amazon.
   • Handle parameters securely.
   • Validate state parameters to prevent cross-site request forgery.
4. Guide sellers to find your app in the Selling Partner Appstore and have them choose Authorize Now.
5. Process the authorization response from Amazon, including:
   • Authorization code.
   • State verification.
   • Selling partner ID.
6. Exchange the authorization code for a refresh token.
7. Store the refresh token securely.
8. During runtime, before you call the SP-API, exchange the refresh token for an access token to include in the API call.
9. Test your authorization workflow to ensure that your application can exchange parameters with Amazon and receive authorization information. To test in beta:
   1. Include the version=beta parameter in your authorization URI.
   2. Navigate to your authorization URI (instead of to the Selling Partner Appstore, as sellers will do).
10. Make sure that your seller regenerates the refresh token annually. For details, refer to Renew Selling Partner Appstore Authorization Workflow.

Steps to set up website authorization workflow (public applications only)

The following steps explain how to set up authorization when sellers visit your website and authorize your application through an Authorize button that you add to your website. For more information, refer to Website Authorization Workflow.

1. Configure your website as follows:
   • Set the referrer-policy no-referrer HTTP header to prevent cross-site request forgery.
   • Set up regional sign-in if you support multiple regions.
2. Create a log-in URI page on your website and configure it to:
   • Accept Amazon's request with seller authentication parameters
   • Allow sellers to log into your website.
   • Associate the Amazon authorization with the correct account in your system.
   • Redirect to Amazon's callback URI with the required parameters.
3. Create a dedicated redirect URI page on your website (for example, https://www.example.com/sp-api/auth) and configure it to:
   • Receive authorization responses from Amazon.
   • Handle parameters securely.
   • Validate state parameters to prevent cross-site request forgery.
4. Build the Seller Central authorization URI for seller login as follows:
   1. Start with the Seller Central URI for your target marketplace.
   2. Add /apps/authorize/consent.
   3. Add a placeholder for your application ID. (You get an application ID from the Solution Provider Portal after you register your application in Step 7: Register Your Production Application.)
   4. If you're testing, add version=beta.
      An example of a full OAuth authorization URI is https://sellercentral.amazon.com/apps/authorize/consent/your-app-id?version=beta
5. Create a log-in page with an authorization button. Set up the authorization button to:
   • Redirect to the Seller Central authorization URI.
   • Include required parameters (redirect URI, state token, and version if testing).
6. Process the authorization response from Amazon, including:
   • Authorization code.
   • State verification.
   • Selling partner ID.
7. Exchange the authorization code for a refresh token.
8. Store the refresh token securely.
9. During runtime, before you call the SP-API, exchange the refresh token for an access token to include in the API call.
10. Test your authorization workflow to ensure that your application can exchange parameters with Amazon and receive authorization information. To test in beta:
11. Include the version=beta parameter in your authorization URI.
12. Navigate to your authorization URI.
13. Make sure that your seller regenerates the refresh token annually. For details, refer to Renew Your Website Authorization.

Steps to set up self-authorization workflow (private applications only)

If your application is private, you can self-authorize your application in the Solution Provider Portal. For more information, refer to Self Authorization.

1. Sign in to Solution Provider Portal.
2. Locate your application.
3. Next to Edit App, choose Authorize.
4. Select Authorize app for each selling partner account that you want to authorize.
5. Save the refresh token that appears for each authorization.
   This process generates an LWA refresh token with a maximum of 10 authorizations per application.
6. Store the refresh tokens securely.
7. During runtime, before you call the SP-API, exchange the refresh token for an access token to include in the API call.

Next steps

Proceed to Step 7: Register Your Production Application.