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 — and SigV4 isn't the only Amazon change with a date on it, since Orders v0 and Finances v0 have published removal dates. 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.