4xx client errorNot retryable as isAuthorization, not authentication

403 Forbidden

The server understood the request and refuses to carry it out. Unlike with 401, fresh credentials for the same identity won't change the answer: the account, the key or the network location isn't allowed.

Open JWT Decoder See which scopes or roles the token carries.

Common causes

The token is valid but lacks the scope or role the endpoint needs (read:orders but not write:orders).
The API key is restricted to other IP addresses, referrers or apps.
A web server can't read the file (Unix permissions), or directory listing is off and the directory has no index file.
A firewall rule (Cloudflare, AWS WAF, ModSecurity) matched something in the request: the user agent, the country, a pattern in the body.
A CSRF check failed on a form post: the token is missing or belongs to another session.

How to fix it

Decode the token and compare its scope or roles claim with what the endpoint's documentation asks for.
If the body is an HTML page from a CDN or firewall rather than your API's JSON, the block happened in front of your server. Look in the firewall's event log, not in the application's.
On a static site, check ownership and permissions: 644 for files and 755 for directories on most setups.
A request that fails in the browser while the same curl works points to something the browser adds: the Origin or Referer header, or cookies.

403 or 404?

A server may answer 404 instead of 403 to hide that a resource exists at all; GitHub does this for private repositories. If a URL you know exists returns 404 for some accounts only, the server is probably hiding a 403 behind it.

403 or 401?

401 asks for credentials; 403 has them and says no. See the 401 guide for the authentication side.

Example

HTTP/1.1 403 Forbidden
Content-Type: application/problem+json

{
  "title": "Insufficient scope",
  "status": 403,
  "detail": "This endpoint requires the scope write:orders."
}

Defined in RFC 9110, section 15.5.4.