Can't make requests to regions other than North America with a self-authorized app

[jlevers]

I'm working with a client to try to expand their Selling Partner API application to the European and Far East markets, but for some reason I can't make requests to the EU and FE endpoints with their credentials. They've created support tickets related to this issue and been told that their credentials should work globally, so their application for developer credentials in Europe has been denied.

However, when I try to make a request to one of the non-NA endpoints, I get this infamous error:

{
  "errors": [
    {
      "message": "Access to requested resource is denied.",
     "code": "Unauthorized",
     "details": ""
    }
  ]
}

When I try the exact same request, using the LWA and AWS info for another app I'm working on that was created from the Develop Apps page of the EU Seller Central dashboard (in a different Seller Central account), everything works fine. This implies to me that this is not an issue with the STS URL I'm using, or the region I'm specifying, because the code behaves as expected when I use credentials from an app created on the Develop Apps page of my EU dashboard.

This issue crops up both when I use authentication code that I personally wrote, and when using the pre-written Java SDK that provides the authentication logic. I've tried using my personal SP API credentials as well, and those also fail when I try to use the EU or NA endpoints.

Could someone from Amazon please provide some insight into what might be going on here? Thank you :)

[jlevers]

After doing more research, and talking with @charliecode and @rogersv about this issue, here's a more full picture of the issue.

It seems that self authorization only enables you to make requests to the endpoint that corresponds to the region that your developer account was authorized in. In other words, if you have access to the North America and Europe regions, and applied for a developer account from your North America Seller Central dashboard, self authorization will not allow you to make requests to the EU endpoint (https://sellingpartnerapi-eu.amazon.com/).

It seems likely that if you submit an app to the Marketplace Appstore, you could formally authorize your own app from your Europe Seller Central dashboard, and then the app would be able to make requests to the EU endpoint on your behalf. If that's the only way around this problem, the self-authorization process is unusable for multi-region apps. If you who want to make a multi-region app for internal use only, it seems that you still have to list it on the Marketplace Appstore and wait for it to be approved by Amazon before it can be used on regions other than the region that your developer account is connected to.

In addition, if you apply for a developer account in multiple regions, the applications in the regions you applied to later will be rejected on the grounds that the developer accounts have "global access." That's technically true, but with the major caveats described above. This is a blocker for anyone making multi-region applications.

Thank you to everyone at Amazon working on improving this API -- you all are moving quickly, and I'm hopeful that this issue will be resolved quickly.

[charliecode]

@jlevers Great write up on this issue Jesse. I'm def going to continue following up on this. If what you're experiencing is indeed the current functionality, then I believe a good amount of our community would definitely benefit from the SP-API team taking a closer look into this and making the necessary changes.

[parvathm]

Hi @jlevers Thank you for taking time to clearly explain the issue. Appreciate it.
We have relayed it to our product team for consideration.

Thanks, Parvathm Seller Partner API Developer Support.

[jlevers]

@parvathm no problem, thanks for looking into it! Any idea when this will be fixed? I'm trying to provide my client with a timeline for when we'll be able to implement the functionality they're looking for, and it's dependent on this.

[cohlar]

@parvathm same here. Our app is in beta in North America, we have a client in Amazon Europe and we cannot access his data at the moment - would be grateful to hear back from you on potential workarounds or when we can expect to have a working solution to this problem 🙏

[melkelk]

I believe this issue is related to the (internal) setup by Amazon for 'developer accounts' in the EU region. I am currently employed by a company in the Amazon Vendor program to integrate the SPAPI and all endpoints give the mentioned 'access-denied errors without details'. Even non-existing paths (..).

It looks to me like the authorization with AWS is actually working but the backend does not find any valid API endpoints available to the seller/vendor account.

[gcarignano]

Same problem here, and I used to have the MWS credentials but now they do not allow me to create MWS apps, which could solve this issue temporarily.

I have registered an app in the US region and one app on the EU region with the same IAM user and I still get the same problem using the new app credentials, so this seems something beyond custom region credentials (I have also self authorized the EU app)

[jlevers]

@parvathm @seanevan would it be possible to get a status update on this issue, or a timeline for when it's going to be fixed? It's an ongoing issue for me, and for the people who've responded above.

[cohlar]

I have a script running on MWS and the inventory for Europe is wrong since Jan 1. Also as of last week, there were still no separate inventory limits for the UK and the EU in Seller Central. So I assume its related to a wider issue in Amazon's backend. My guess is they are still adjusting to Brexit.

[torro-uk]

Had there been any updates on this issue? We sell in all 3 regions and have an app which aggregates the data from all of our marketplaces into a single dashboard. We are using the existing MWS API.

We have created a new “SP API” app, self-authorised in both UK and US seller central accounts. The UK app works fine and allows us to get data from the various EU marketplaces but the US app doesn’t connect - despite being setup in the exact same way! I assume this is related to the issue reported above?

I was hoping the new API would make things easier but this doesn’t seem to be the case! Other than using JSON instead of XML it’s not that much better when working with orders. Splitting orders info into separate areas for order headers, buyer info, address and items means I now likely have to make more API calls to get the data we need!

Why can’t a request to the Order API return an entire order record and not just part of it!?

Any further input into this matter would be greatly appreciated as we can’t even consider migrating until we can access ALL regions.

thanks, Rob

[wmh49877]

Encountered the same problem, unable to proceed to the next step , Sandbox environment feeds api return is always unauthorized

[torro-uk]

Surely there has been some movement on this issue? They have announced that we need to migrate by September 30th but without the ability to access all three regions this is just not going to happen!!

Has anyone found a way of accessing multiple regions from the same developer account?

[kumarparekh]

Hi Everyone, Did anyone figure out a solution to this? We even tried to get developer credentials using another persons Seller account which is primarily registered for UK. We are able to authorise other countries by UK/Europe. Any help or solution will be greatly appreciated.

[torro-uk]

Hi,

I managed to get this working for us, but it involved creating a new App in each of the 3 Regional Seller Centrals (UK, US, AUS) and then we swap between the various login credentials to access the data from each regions.

The other issue it took me quite some time to realise is that the library I was using to access the API was caching the tokens in a local file and so when I switched region it was trying to use the previous tokens which obviously didn't work! I used to library to clear the cache when region switching and now I can access data from every marketplace.

Not sure if this helps or not? All 3 account were setup the same and use the same ARN user etc.

[LukeLim81]

@parvathm: Can you clarify if we need to create a different App in each of the seller central, or can we just have one created in US and having access to global region?

[ulandj]

Can you clarify if we need to create a different App in each of the seller central, or can we just have one created in US and having access to global region?

https://github.com/amzn/selling-partner-api-docs/blob/main/guides/en-US/developer-guide/SellingPartnerApiDeveloperGuide.md#global-applications

[xEverth]

Linked resource was migrated, only mention of "global applications" is found on the new docs: https://developer-docs.amazon.com/sp-api/docs/authorization-errors#access-to-requested-resource-is-denied

It states:

Region mismatch: Ensure that the seller account you are making a request to and the request endpoint are in the same region. The Selling Partner application is global but seller accounts are not. Refer to SP-API Endpoints for more information.

Nonetheless, as others mentioned above, having a self-authorized private application seems to be incompatible with accounts that sell in multiple regions. The current solution seems to be creating different apps, one for each region, that are all self authorized and then switching the credentials in the client application.

Can someone confirm if there is a different solution to this issue in 2023?

[jlevers]

In my experience, it's possible to generate a separate refresh token for each region using a single application (i.e., not one application per region). So you have one LWA client ID/client secret pair, and multiple refresh tokens. For whatever reason it seems that in the FE region you need to generate a separate refresh token for every country (AU/JP/SG) rather than one for the whole region, but I am now successfully making requests across multiple regions for at least one of my clients (I think possibly more) using a single SP API app and per-region self-authorized refresh tokens.