Amazon SP-API 403 Unauthorized: Every Cause and How to Fix It

You've got working credentials, an access token comes back fine, and then the call returns this:

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

The frustrating part: a 403 rarely means your Login-with-Amazon (LWA) credentials are wrong. If the client ID, client secret, or refresh token were bad, you'd get a 401 or a token-grant error before you ever reached the operation. A 403 means you authenticated fine, but you're not allowed to do this specific thing — a role, a region, an authorization scope, or a restricted-data requirement is out of alignment.

This is the single most common cause. Every SP-API operation requires a specific role (Inventory & Order Tracking, Pricing, Direct-to-Consumer Shipping, etc.). If your application wasn't registered with the role that operation needs, you get a 403 — even though the same token happily calls other endpoints.

• Check the operation's reference page for its required role.
• Confirm your app has that role in the Developer Central / Solution Provider Portal app config.
• The catch that traps everyone: if you added a role after the seller already authorized your app, the existing refresh token does not carry the new role. The seller must re-authorize so a fresh refresh token is minted with the expanded scope.

Operations that return personally identifiable information — buyer name, shipping address, buyer email, on getOrder, getOrderItems, getOrderAddress, and the reports that contain PII — will return a 403 (or silently redacted fields) if you call them with a normal access token.

These require a Restricted Data Token (RDT): you call the Tokens API first, describe the exact restricted resource you want, get back a short-lived RDT, and use that as the x-amz-access-token for the PII call.

POST /tokens/2021-03-01/restrictedDataToken
{
  "restrictedResources": [
    { "method": "GET", "path": "/orders/v0/orders/{orderId}/address",
      "dataElements": ["shippingAddress"] }
  ]
}

If you request an RDT for a path or data element your app's roles don't cover, the RDT request itself 403s — which loops you back to Cause 1 (you need the Direct-to-Consumer Shipping / PII role first).

SP-API has three regional endpoints, and your authorization is region-bound. Call the wrong one and you get a 403, because your token has no authority in that region.

A US seller's token used against the EU endpoint is a classic 403. Match the endpoint to the marketplace the seller authorized in.

For a public/multi-seller app, a 403 on a specific seller's data usually means that seller's authorization is missing or was revoked. Your refresh token maps to one selling partner; if that grant is gone, so is your access.

• Confirm the seller completed the OAuth authorization flow (not just installed a draft).
• Check whether the seller revoked access in Manage Your Apps.
• If a seller re-authorized, make sure you're using the newest refresh token, not a stale cached one.

Even within the right region, a seller may have authorized you for some marketplaces and not others. Passing a marketplaceIds value the seller didn't grant returns a 403. Call GET /sellers/v1/marketplaceParticipations with the token to see exactly which marketplaces that authorization covers, and only pass those.

A draft app can self-authorize and hit production for your own account, but it's limited to the roles you configured. If you're calling an operation whose role you didn't attach to the draft — or an operation gated behind an approval you don't have — that's a 403. Add the role in the app config, then self-authorize again to regenerate the token with the new scope.

Amazon dropped the AWS SigV4 signing requirement for SP-API in 2023 — you no longer need an IAM user, role ARN, or STS AssumeRole call. If you inherited older code that still signs requests with AWS credentials and assumes a role, a broken or expired IAM setup can surface as a 403. The fix is usually to remove the SigV4 layer entirely and send just the LWA access token in x-amz-access-token.

Throttling normally returns 429, not 403 — but under burst conditions, or through certain proxies and gateways, aggressive rate-limit behavior can present confusingly. Read the x-amzn-RateLimit-Limit response header, back off exponentially on 429, and never poll the Reports API in a tight loop. If your 403s correlate with request volume rather than a specific operation, treat it as a rate problem first.

When a 403 lands, check in this order — it resolves the vast majority in minutes:

• Is it a PII operation? → you need an RDT (Cause 2).
• Does the operation's required role match your app's roles? → grant it and re-authorize (Cause 1).
• Right regional endpoint for this marketplace? → fix the host (Cause 3).
• Is this marketplace in the authorization? → check marketplaceParticipations (Cause 5).
• Is the seller still authorized? → re-consent if needed (Cause 4).
• Any old AWS SigV4 code in the path? → remove it (Cause 7).

Why do I get a 403 on getOrder but not on getOrders?

Because getOrder can return buyer PII (name, address) and getOrders at the list level may not. PII-bearing operations require a Restricted Data Token and the Direct-to-Consumer Shipping role; the list call often doesn't.

Is a 403 a credentials problem?

Almost never. Bad credentials produce a 401 or a failed token grant. A 403 means you authenticated successfully but aren't authorized for that specific operation, marketplace, region, or data element.

I added a role but still get 403. Why?

Adding a role in the app config isn't enough — the seller (or you, for a private app) must re-authorize so a new refresh token is issued that carries the added role. Old tokens keep their original, narrower scope.

Do I still need AWS IAM credentials for SP-API?

No. Amazon removed the AWS SigV4 signing requirement in 2023. You only need your LWA access token. Leftover IAM/SigV4 code is now a common source of confusing 403s.

Does throttling cause a 403?

Throttling is normally a 429. But in bursty conditions it can look like access denial. Check the rate-limit headers and back off before assuming a permissions issue if the errors track request volume.