This is a 403 and it has several distinct causes that produce the same message. In order of how often they actually occur: the seller account and the endpoint are in different regions, your application lacks the SP-API role required for the operation, the seller has not authorised your application for that data, or the credentials are expired or the request signature is wrong. Region mismatch is the one that catches most teams, because everything else about the setup is correct and the request simply goes to the wrong regional endpoint.
One message, several causes
A 403 with this message is deliberately unspecific. Amazon does not tell you which check failed, because doing so would help someone probing for access.
That leaves you distinguishing the causes by their pattern rather than by the message. Fortunately the patterns are quite distinct.
The causes, in order of frequency
1. Region mismatch. SP-API is served from regional endpoints and a seller account lives in one region. Sending a request for a European seller to the North America endpoint fails, however correct everything else is. Marketplace ID and endpoint region must agree.
This is the most common cause and the cheapest to check, so check it first.
2. Missing SP-API role. Roles gate categories of data: finance, ordering, listings, restricted personal information. Your application is approved for specific roles. Calling an operation outside them is denied.
3. Seller has not authorised your application for the data in question, or the authorisation was withdrawn.
4. Expired or invalid credentials, or a request signature that does not validate.
Telling them apart
Pattern
Points to
Every call denied, immediately, from the start
Region or credentials
Every call denied, but it worked yesterday
Expired or revoked authorisation
Most calls fine, one family denied
Missing role
Works for one marketplace, not another
Region, or per-marketplace authorisation
Works for one seller, not another
That seller’s authorisation
The third row is the useful one. Selective failure means configuration, total failure means credentials. That single distinction removes most of the search space before you have opened any documentation.
Checking it
Compare the endpoint region against the seller’s marketplace. Rule out the most common cause in a minute.
List which operations fail and which succeed. Selective failure means roles.
Check what the seller actually authorised, per marketplace, not in general.
Check what your application is approved for. Restricted data needs approval beyond seller consent.
Only then look at token expiry and request signing. These are real causes but they are rarely the ones people miss, because they fail loudly and totally.
Why this needs watching, not just fixing
Access to SP-API is not a one-time setup. Authorisations expire, sellers change their app permissions, Amazon adjusts what roles cover, and a marketplace expansion introduces a region that was never configured.
An integration built once will eventually lose access to something it had, and the failure mode is quiet: orders stop arriving, and unless someone is watching for the absence, the first symptom is a gap in your data discovered days later.
We monitor authorisation validity, not just call outcomes. An approaching expiry is scheduled work.
Absence is an alarm. If a marketplace stops delivering orders, that is an alert even though nothing returned an error.
Region and marketplace configuration are explicit per seller, so adding a marketplace is a deliberate change rather than a discovery made through 403s.
We track SP-API role and policy changes, so an approval requirement that changes reaches us before it reaches your order flow.
Frequently asked questions
What does region mismatch mean in practice?
SP-API is served from regional endpoints, and a seller account belongs to a region. A request for a European seller sent to the North America endpoint is denied, even with perfectly valid credentials, because you are asking the wrong regional service about an account it does not hold. Marketplace ID and endpoint region have to agree. This is the first thing to check because it is both the most common cause and the fastest to rule out.
How do I know if a role is missing?
Roles gate categories of data. Finance, ordering, product listings and personally identifiable information are separate grants, and applications are approved for specific ones. If most calls succeed and a specific family of calls is denied, that pattern points at a missing role rather than a credential problem. A credential problem denies everything.
The seller authorised us, but we still get 403.
Authorisation and roles are two different things. A seller can authorise your application while your application still lacks approval for the role that operation needs. Check both: what the seller granted you, and what your application is approved for. Restricted data in particular requires a separate approval beyond the seller's consent.
It worked yesterday and fails today.
Then look at expiry and revocation rather than configuration. Refresh tokens can be revoked, sellers can remove an authorisation, and role approvals can lapse. A configuration cause would not have worked yesterday. A sudden change points at something that expired or was withdrawn.
How do you keep this from becoming an outage?
By monitoring the validity of authorisations rather than waiting for calls to fail. An authorisation with a known expiry is a scheduled task. An authorisation that expires unnoticed is a silent stop in your order flow, and you find out from the gap in your data rather than from an alert.
// scoping request
Seeing this in production and want it to stop being your problem? We design, build, and permanently operate the pipeline, including the validation and retry logic that stops this class of failure reaching you. Fixed-price scoping quote within 48 hours.