Authorizing Selling Partner API Applications
Authorize SP-API apps
The authorization model for the Selling Partner API is based on Login with Amazon, Amazon's implementation of OAuth 2.0. In this model your application is authorized through interactions with pages displayed by Amazon and by your website. The web browser is the user-agent that passes parameters between your website and Amazon at each selling partner action. To implement OAuth authorization you must configure your website to (1) accept and process the parameters that Amazon passes to it, and (2) redirect the web browser and pass parameters to Amazon.
How is my application authorized?
-
Public applications for sellers: Applications that are publicly available and are authorized by sellers. These applications can be authorized using the following methods:
- Selling Partner Appstore authorization workflow An OAuth authorization workflow initiated from the Selling Partner Appstore detail page.
- Website authorization workflow An OAuth authorization workflow initiated from your own website.
-
Public applications for vendors: Applications that are publicly available and are authorized by vendors. These applications can be authorized using the following method:
- Website authorization workflow An OAuth authorization workflow initiated from your own website.
-
Private applications for sellers or vendors: Applications that are available only to your organization. These can be seller or vendor applications. These applications can be authorized using the following method:
Note
You can call Grantless operations without explicit authorization from a selling partner.
For more information, refer to Terminology.
Construct an OAuth authorization URI
An OAuth authorization URI is a key component for creating and testing Selling Partner API authorization workflows. The OAuth authorization URI redirects a browser to an Amazon consent page, where you or a selling partner can give your application consent to make calls to the Selling Partner API.
If a selling partner authorizes your application starting from your own website using the Website authorization workflow, then your website uses an OAuth authorization URI to redirect the selling partner to the Amazon consent page. Even if a selling partner authorizes your application starting from the Selling Partner Appstore, the Selling Partner appstore authorization workflow, you still need an OAuth authorization URI to test your authorization workflow in draft status before creating a live listing in the Selling Partner Appstore.
When constructing an OAuth authorization URI, applications are grouped into two types:
-
All public applications and private seller applications: This can be: (1) Applications that are publicly available and are authorized by a seller or by a vendor, and (2) Seller applications that are available only to your organization, and are self-authorized.
-
Private vendor applications: Vendor applications that are available only to your organization, and are self-authorized.
The following procedures explain how to construct an OAuth authorization URI, depending on the application type.
Note
You can find the application ID following the application name on the developer console.
Construct an OAuth authorization URI for public seller applications
-
Get the Seller Central URL for the marketplace where you want selling partners to authorize your application. Refer to Seller Central URLs for a list of URLs by marketplace. Example:
https://sellercentral.amazon.com
-
Combine the Seller Central URL with
/apps/authorize/consent?application_id={your application ID}
.Example:
https://sellercentral.amazon.com/apps/authorize/consent?application_id=amzn1.sellerapps.app.0bf296b5-36a6-4942-a13e-EXAMPLEfcd28
Construct an OAuth authorization URI for public vendor applications
-
Get the Vendor Central URL for the marketplace where you want selling partners to authorize your application. Refer to Vendor Central URLs for a list of URLs by marketplace. Example:
https://vendorcentral.amazon.com
-
Combine the Vendor Central URL with
/apps/authorize/consent?{your application ID}
.Example:
https://vendorcentral.amazon.com/apps/authorize/consent?application_id=amzn1.sellerapps.app.0bf296b5-36a6-4942-a13e-EXAMPLEfcd28
You must construct OAuth authorization URIs for the marketplaces in which selling partners will authorize your application. For example, if a seller has a Seller Central account for Mexico, they will need an OAuth authorization URI for Mexico (example: https://sellercentral.amazon.com.rproxy.goskope.com.mx/apps/authorize/consent?application_id=amzn1.sellerapps.app.0bf296b5-36a6-4942-a13e-EXAMPLEfcd28
) to initiate authorization of your application. Authorizations are regional. When the authorization is complete, your application will have access to the seller's account in any marketplace in the North America region. The same concepts apply to vendors using Vendor Central. You can use the GetMarketplaceParticipations API to discover the active marketplaces for a selling partner.
If you are creating an OAuth authorization URI for testing your authorization workflow, add the version=beta parameter. This indicates that the authorization workflow is for an application in draft status. Example: https://sellercentral-europe.amazon.com/apps/authorize/consent?application_id=amzn1.sellerapps.app.0bf296b5-36a6-4942-a13e-EXAMPLEfcd28&version=beta
For information about creating and testing an authorization workflow, refer to Selling Partner Appstore authorization workflow and Website authorization workflow.
Updated 15 days ago