Amazon Selling Partner API - spapi.cyou

Authorizing Selling Partner API applications

AmazonSPAPI

# Authorizing Selling Partner API applications

The authorization model for the Selling Partner API is based on Login with Amazon (opens new window), Amazon's implementation of OAuth 2.0. In this model the selling partner authorizes your application by interacting with pages displayed by Amazon and by your website. Actions taken by the selling partner trigger responses by your website or by Amazon. The selling partner's 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 selling partner’s browser and pass parameters to Amazon.

# How is my application authorized?

The way your applications are authorized depends on the application type. Here are applications types grouped by how they are authorized:

  • Public applications for sellers. Applications that are publicly available and are authorized by sellers. These applications can be authorized using the following methods:

  • Public applications for vendors. Applications that are publicly available and are authorized by vendors. These applications can be authorized using the following method:

  • 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, see Terminology.

# Constructing 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 a selling partner can give your application consent to make calls to the Selling Partner API on their behalf. If the selling partner is not signed into Seller Central (for sellers) or Vendor Central (for vendors), a sign-in page appears first.

If a selling partner authorizes your application starting from your own website using the Website authorization workflow; 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 Amazon Seller Central Partner Network (ASCPN), the ASCPN authorization workflow, you still need an OAuth authorization URI to test your authorization workflow in draft status before creating a live listing in the ASCPN.

For the purposes of 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.

For more information, see Terminology.

The following procedures show you how to construct an OAuth authorization URI, depending on the application type:

To construct an OAuth authorization URI (for all public applications and private seller applications)

  1. Get the Seller Central URL for the marketplace where you want selling partners to authorize your application. See Seller Central URLs for a list of URLs by marketplace. Example: https://sellercentral.amazon.com

  2. 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

To construct an OAuth authorization URI (for private vendor applications)

  1. Get the Vendor Central URL for the marketplace where you want selling partners to authorize your application. See Vendor Central URLs for a list of URLs by marketplace. Example: https://vendorcentral.amazon.com

  2. 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 need to 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.mx/apps/authorize/consent?application_id=amzn1.sellerapps.app.0bf296b5-36a6-4942-a13e-EXAMPLEfcd28) to initiate authorization of your application. Authorizations are regional, so 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.

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, see ASCPN authorization workflow and Website authorization workflow.

# Migrating authorization from Amazon Marketplace Web Service (MWS)

For seller applications only.

If a seller has authorized you to make calls to Amazon MWS on their behalf, you can use the Authorization API to migrate that authorization to a hybrid Selling Partner API application. This eliminates the need to request authorization from the selling partner again. For more information, see the Authorization API Use Case Guide.

Brand Analytics role