Authorize Private Applications

Before your private application can call the Selling Partner API (SP-API) on behalf of your organization, you must authorize the application to access your account information. This process is called self-authorization. You can self-authorize your application in draft status because there is no reason to publish a private application.

This topic explains how to self-authorize your private application. If your application is public, a selling partner must authorize your application. In this case, refer to Authorize Public Applications.

Self-authorization workflow

The following table shows the authorization flow when you self-authorize your private application.

Authorization details

The following sections provide additional information about specific elements of the authorization process.

Tool sign-in details

To begin the self-authorization process, sign in to one of the following tools:

• Solution Provider Portal: To authorize a Seller Central account, use the sign-in link on the Manage Authorizations page.
• Seller Central: Choose Apps and Services, and then choose Develop Apps.
• Vendor Central: Choose Integration, and then choose API Integration. Administrators can also authorize apps for each vendor group.

Generate a refresh token

A refresh token is a long-lived credential that your application uses to get new access tokens when you call the SP-API. To generate a refresh token, take the following steps:

1. Navigate to the Authorize application page of the Solution Provider Portal, Seller Central, or Vendor Central.

2. Choose Authorize app for each selling partner account that you want your application to access. Each time you choose Authorize app, a new refresh token appears. Generating a new refresh token doesn't invalidate previous refresh tokens.

   For selling partner accounts that are merged with accounts in other regions: The Authorize app button appears for each of your merged accounts.

Token storage details

When you store refresh tokens, follow these security best practices:

• Store tokens in a secure, encrypted database.
• Never store tokens in client-side code or logs.
• Never share or expose tokens in URLs.
• Implement secure backup and recovery procedures for your token database.
• Create an access control system that restricts token access to only the necessary parts of your application.
• Implement a process to handle token rotation and revocation.

Runtime token exchange details

During runtime, unless the operation is grantless or accesses restricted data, your application exchanges a refresh token for an access token. To exchange a refresh token for an access token, your application sends a POST request to the Login with Amazon (LWA) authorization server (https://api.amazon.com/auth/o2/token) with the following parameters:

Example request to exchange a refresh token for an access token:

POST /auth/o2/token HTTP/1.1
Host: api.amazon.com
Content-Type: application/x-www-form-urlencoded;charset=UTF-8

grant_type=refresh_token&refresh_token=Atzr|IQEBLzAtAhexample&client_id=foodev&client_secret=EXAMPLESECRET

The LWA server returns a JSON response with the following parameters:

Example response that contains an access token:

{
  "access_token": "Atza|IQEBLjAsAexampleHpi0U-Dme37rR6CuUpSR",
  "token_type": "bearer",
  "expires_in": 3600
}

Use the returned access token in the authorization header of your SP-API requests. For more information about making SP-API calls, refer to Connect to the Selling Partner API.

You can also use an SDK to help you with this step. For details, refer to SP-API SDK.