Twitter API 403 Forbidden and 401 Unauthorized: Every Cause and Fix

A 403 and a 401 look similar in a log line and mean opposite things. One says X does not know who you are. The other says X knows exactly who you are and is refusing anyway. Debugging them the same way is why these two errors eat entire afternoons.

This is the full list of causes for each, with the fix, and how to tell them apart in one step.

The one-line difference

	What X is saying	Where to look
401 Unauthorized	"I cannot verify who you are"	The credentials themselves
403 Forbidden	"I know who you are, and no"	Your tier, permissions, or account state

The practical consequence: regenerating your keys fixes many 401s and almost never fixes a 403. If you are reaching for the regenerate button on a 403, stop. The 403 already proves your key worked.

Read the body, not the status

Both errors carry the real reason in the response body, and the status code alone is not enough to act on. X returns a detail or errors array explaining the refusal, and it is far more specific than the HTTP code:

{
  "title": "Unsupported Authentication",
  "detail": "Authenticating with OAuth 2.0 Application-Only is forbidden for this endpoint.",
  "status": 403
}

That message names the exact problem. Logging only 403 throws it away. Log the body.

X documents the full status and error-code list in error troubleshooting guide, and the per-endpoint access rules in the X API documentation. Every code cited below is from those references, checked on July 29, 2026.

Every cause of 403 Forbidden

A 403 always means your credentials were accepted and the action was refused anyway. There are seven distinct causes, and none of them are fixed by changing your key.

1. The endpoint is not in your access tier

The most common cause since 2023, and the one that appears out of nowhere. Tier entitlements have been cut repeatedly, so an endpoint that worked under your tier may simply no longer be included.

Fix: confirm the endpoint is still in your current tier. If it is not, the only remedies on the official platform are upgrading or changing approach.

2. App permissions are Read-only and you are writing

Reading and writing are separate entitlements. An app defaulted to Read returns 403 on every write no matter how valid the credentials are.

Fix: set the app to Read and Write in the developer portal, then regenerate the access token and secret. This second step is the one people miss. Tokens minted under the old permission level keep the old scope forever, so the change does nothing until the token is reissued.

3. The app is not attached to a Project

v2 endpoints require the app to sit inside a Project. A standalone app authenticates fine and then 403s on every v2 call.

Fix: attach the app to a Project in the developer portal.

4. Wrong authentication type for the endpoint

Some endpoints require user context (OAuth 1.0a or OAuth 2.0 with PKCE) and reject app-only bearer tokens. This produces the Unsupported Authentication message shown above.

Fix: switch to user-context auth for that endpoint. Anything acting on behalf of a specific account needs it.

5. Account suspended, locked, or restricted

If the authenticating account or the target account is suspended, the action is refused regardless of credentials.

Fix: check the account state. Codes 64 (your account is suspended) and 63 (target account suspended) identify this precisely. Code 326 means temporarily locked, which you clear at x.com/account/access before retrying.

6. The action needs X Premium

Some actions are Premium-gated. Code 433 covers both a reply-gated tweet and an action requiring Premium.

Fix: use a Premium account, or drop the action.

7. Duplicate or limit-hit writes

A repeated tweet returns code 187. A daily ceiling on DM requests returns 502, carried inside an HTTP 429. Code 344 looks similar but is not a daily account ceiling: it is posting throttled at the network or IP level. These are refusals rather than auth failures.

Fix: for 187, change the content. For 502, wait out the 24-hour window. For 344, retry shortly or post from a clean dedicated IP, since switching accounts does not help when the throttle is on the egress address.

Every cause of 401 Unauthorized

A 401 always means X could not verify the credentials at all. Six causes, and every one of them lives in how the request was authenticated rather than what it asked for.

1. Stale credentials after a regeneration

Regenerating keys invalidates the old pair instantly. Any cached copy in an env file, a CI secret, or a running process keeps failing until it is replaced everywhere.

Fix: update every location, then restart the process. A running server holds the old value in memory.

2. Expired OAuth 2.0 access token

OAuth 2.0 access tokens are short-lived. If you never implemented refresh, everything works for a couple of hours after each manual authorisation and then 401s.

Fix: implement the refresh flow, and refresh before expiry rather than after a failure.

3. OAuth 1.0a signature built wrong

The most fiddly source of 401s. The signature base string must include every request parameter, percent-encoded, sorted, with the exact HTTP method and full URL. One extra query parameter left out of the base string invalidates the whole signature.

Fix: use a maintained OAuth library rather than hand-rolling it. If you must debug it, print the base string and compare it character by character against the request you actually sent.

4. Server clock skew

OAuth 1.0a signatures carry a timestamp and X rejects requests too far outside its own clock. A container with a drifting clock produces 401s that look random.

Fix: run NTP. This is worth checking early because it is invisible in application logs.

5. Bearer token sent to a user-context endpoint

Sending app-only credentials where user context is required can surface as 401 rather than 403 depending on the endpoint.

Fix: match the auth type to the endpoint.

6. Invalid or expired auth_token

Error code 32, could not authenticate you, means the token is dead.

Fix: re-mint it.

X error codes worth branching on

The HTTP status tells you the category. X's own numeric code tells you what actually happened, and it is what your retry logic should branch on:

Code	Meaning	Retry helps?
32	Could not authenticate you	No, re-mint the token
63	Target account suspended	No
64	Your account is suspended	No, use another account
131	Temporary X internal error	Yes
187	Duplicate tweet	No, change the text or wait
226	Request looked automated	Yes
326	Account temporarily locked	After unlocking
344	Posting throttled at the network or IP level, not the account	Yes, shortly, or from a clean dedicated IP
433	Reply restricted or Premium required	No
502	Daily DM request limit reached	After 24 hours

Source for the code meanings and retry guidance: the GetXAPI error reference, which passes X's own twitter_error_code straight through, cross-checked against X's error troubleshooting guide.

The distinction that matters for a retry loop: 131, 226 and 344 clear on their own and are worth retrying with backoff, though 344 is a network or IP throttle, so retry from a clean dedicated address rather than a different account. The rest of that table needs something to change first, whether that is the content, the target's state, your access level or your credentials, so retrying them unchanged only spends quota.

A diagnostic order that actually converges

1. Log the response body. The detail field usually names the cause outright.
2. Split on the status. 401 sends you to the credentials. 403 sends you to tier, permissions and account state. Do not cross the streams.
3. On a 403, check permissions before anything else, and remember to reissue the token after changing them.
4. On a 401, check for a stale credential before touching the signing code. It is far more often a cached key than broken OAuth.
5. Branch on twitter_error_code, not the HTTP status, so your retry logic distinguishes a transient 131 from a duplicate-text 187, which needs the content or timing to change.

Removing the whole class of problem

Most of the causes above are artefacts of the official developer platform rather than anything about the data. Tier gating, app permissions, Project attachment, OAuth signing and token refresh are all platform mechanics, and every one is a way to get a 403 or 401 while your request itself was fine.

GetXAPI authenticates with a single bearer token. There are no access tiers, no app permission settings, no Project to attach to, no OAuth signature to build and no token to refresh:

curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://api.getxapi.com/twitter/user/info?userName=elonmusk"

That removes causes 1 through 4 of the 403 list and 1 through 5 of the 401 list, because none of those mechanisms exist. What remains is the genuinely X-side category: a suspended account, a locked account, a duplicate tweet. Those still occur, and GetXAPI passes X's own code through as twitter_error_code so you can branch on the real reason. The full mapping is in the error reference.

If your 403 is a tier problem, no amount of debugging will fix it, because the request was never the issue. That is the case worth recognising early.

Related reading

• Every X API error code and its fix, the full reference table if your error is not a 401 or 403
• Twitter API rate limits, for the 429 side of the same problem
• How to get a Twitter API key, if you are still choosing an auth path
• Post tweets via API with authentication, for the write flow end to end