n8n Error Reference

401 Unauthorized

A 401 response means the API rejected the request because it could not verify who is making it. The credentials either weren't sent, were sent in the wrong format, have expired, or don't match what the API expects. The fix is almost always in the credential configuration, not in the workflow logic.

Quick Diagnosis

Open the failed node and check which credential is selected. Then confirm the Authorization header format the API expects — Bearer TOKEN, X-API-Key, or Basic auth. A valid key sent under the wrong header name returns 401 every time.

Error variants

These are the exact strings n8n surfaces for 401 responses — from the HTTP Request node, from built-in service nodes, and from raw API response bodies:

Request failed with status code 401

n8n's HTTP Request node uses Axios internally. This is the Axios error message for any 401 response. It tells you the status code but not the cause — open the node, enable "Include Response Headers and Status" in Options, re-run, and read the response body for the API's specific error message.

ERROR: 401 Unauthorized

This format appears from built-in n8n service nodes — Slack, Airtable, Notion, HubSpot, and others. The node caught the 401 and surfaced it as an n8n error. The most common cause: the wrong credential is selected in the node's credential dropdown, or the selected credential was revoked or regenerated on the API provider side.

HTTP/1.1 401 Unauthorized

The raw HTTP status line, sometimes visible in execution logs or when logging response headers explicitly. This is the server's response before n8n processes it. The response body that follows usually contains a more specific message — look there first before investigating credential configuration.

401 Unauthorized: Invalid API key provided

OpenAI and several other APIs append a plain-English reason after the status. 'Invalid API key provided' means the key itself is wrong or revoked — not just missing or mis-formatted. Open the n8n credential, copy the API key, and test it directly in the provider's dashboard or with a curl request to confirm it's still active.

{"error": "invalid_token", "error_description": "The access token expired"}

OAuth2 access tokens have a limited lifetime. When n8n's automatic token refresh fails — due to an expired refresh token, a revoked OAuth app, or a connectivity issue during the refresh — the next request goes out with the old expired access token and the API returns this response. Re-authorizing the credential in n8n forces a new token exchange.

What this error means

HTTP 401 means the server received the request but cannot authenticate the caller. Authentication is separate from authorization — 401 specifically means identity could not be confirmed, not that the identity lacks permission (that would be 403). In n8n workflows, 401 almost always means the credentials the node sent are missing, formatted incorrectly, expired, or tied to the wrong environment. The API never gets far enough to evaluate what the request is trying to do.

Common causes

Wrong credential selected in the node

n8n stores credentials separately from workflows. If a workflow was imported, duplicated, or the credential was recreated, the node may be pointing to a credential that no longer exists or belongs to a different account. Open the node and check the credential dropdown — the name displayed may not match the active key.

API key sent under the wrong header name

Different APIs expect credentials in different places: Authorization: Bearer TOKEN, Authorization: Basic base64(user:pass), X-API-Key: TOKEN, or a custom header like api-key or token. Sending a valid key under the wrong header name — or in the query string when the API expects a header — returns 401 every time. Check the API's authentication documentation, not just the value of the key.

Expired access token or short-lived credential

OAuth2 access tokens, JWT tokens, and session tokens expire. If n8n's token refresh mechanism fails silently, the next execution sends the expired token. API keys issued with an explicit expiry date do the same. Check the credential's creation date and the API provider's token expiry policy.

OAuth2 token refresh failure

n8n attempts to refresh OAuth2 access tokens automatically using the stored refresh token. If the refresh token itself has expired, the OAuth app was revoked, or the provider rotates refresh tokens on each use (rolling refresh tokens), the refresh fails and the next request is unauthenticated. The workflow may run successfully for weeks before this surfaces.

Sandbox vs. production credential mismatch

APIs like Stripe, PayPal, and many payment processors issue separate keys for sandbox and production environments. A sandbox key sent to a production endpoint — or vice versa — returns 401. The key is syntactically valid so n8n's credential test may pass, but the endpoint rejects it.

API key scope insufficient for the endpoint

Some APIs return 401 (rather than 403) when a key lacks the scope required for the endpoint being called. Stripe, GitHub, and Google APIs are common examples. The key is valid and authenticated, but the specific permission was not granted when the key was created. Check the key's scope or permissions in the API provider's dashboard.

How to diagnose it

1
Open the failed node and check which credential is selected in the credential dropdown. Confirm the credential name matches the service and environment (sandbox vs. production) you intend to target.
2
Open the credential itself in Settings → Credentials. If there is a "Test" button, run it — this sends a real authenticated request and confirms whether the stored key is currently valid.
3
For HTTP Request nodes: enable "Include Response Headers and Status" in the node Options, re-run the execution, and read the response body. The API's error message in the body is almost always more specific than the 401 status code alone.
4
Check the Authorization header format the API expects. Open the API provider's authentication documentation and confirm whether it wants Authorization: Bearer, Authorization: Basic, a custom header, or a query parameter. Compare that to what the node is configured to send.
5
Test the credential independently: copy the API key from the n8n credential and run a minimal curl request directly against the API. If curl also returns 401, the key itself is invalid or expired. If curl succeeds, the problem is in how n8n is sending it.
6
For OAuth2 credentials: open the credential, click Reconnect or Re-authorize, and complete the OAuth flow. This forces a fresh token exchange and clears any expired tokens from the credential store.
7
If the error is intermittent and the workflow ran successfully before: check whether the API key has an expiry date, or whether the OAuth refresh token has a rolling expiry. Tokens that expire after 30 or 90 days produce intermittent 401s that are easy to mistake for a workflow bug.

n8n-specific scenarios

HTTP Request node → Authorization header format mismatch

The node is configured with a valid API key but the Authorization header is formatted incorrectly for the target API. Example: sending Authorization: TOKEN when the API expects Authorization: Bearer TOKEN, or putting the key in a header named api-key when the API checks X-API-Key. In the HTTP Request node, go to the Authentication section, select "Generic Credential Type," and set the header name and format explicitly to match the API documentation.

Built-in service node (Slack, Airtable, Notion) → wrong credential

The node has a credential selected, but it's the wrong one — a credential from a different account, a credential that was revoked when an API key was rotated, or a credential left over from a test environment. Open the node's credential dropdown, select the correct credential, and use the credential test to confirm it's active before re-running.

OpenAI node → "Invalid API key provided"

The API key stored in the n8n OpenAI credential is wrong, revoked, or belongs to a different OpenAI organization. Open platform.openai.com → API Keys and confirm the key is still listed as active. If it was regenerated, create a new credential in n8n with the new key — do not edit the existing credential in place, as other workflows may reference it.

OAuth2 credential → token refresh failure

n8n refreshes OAuth2 access tokens automatically, but if the refresh token expires (Google's default is 6 months of inactivity, some providers use rolling 30-day tokens), the refresh fails silently and the next request goes out unauthenticated. The symptom is a 401 that appears weeks after the credential was created and working. Fix: open the credential, click Reconnect, and complete the OAuth consent flow to issue new tokens. Consider setting a calendar reminder to re-authorize long-lived credentials before their refresh token expires.

Stripe or payment API → sandbox key hitting production endpoint

Stripe prefixes sandbox keys with sk_test_ and production keys with sk_live_. If a workflow built in a test environment is deployed with the sandbox credential still selected, every request to the production Stripe API returns 401. The n8n credential test may succeed (it tests the key format, not the environment). Check the key prefix in the credential and swap it to the production key before going live.

Webhook node → external service not sending auth credentials

n8n Webhook nodes can be configured to require Basic auth or Header auth. If the external service sending data to the webhook is not including the expected Authorization header — because it was set up without auth or the credential was changed on the n8n side — the webhook returns 401 to the sender, which may surface as a delivery failure or silent drop on the sender's side rather than a visible n8n execution error. Check the webhook's auth configuration and confirm the sending service is including the matching header.

Paste your full error message and the failed node's output into Debugalo to get a structured breakdown: the exact failed step, root cause, and concrete fix steps.

Analyze this error →

FAQ

What's the difference between 401 Unauthorized and 403 Forbidden?

401 means the server could not authenticate the caller — it does not know who you are, or cannot verify it. 403 means the server knows who you are but the account or key does not have permission to access the resource. In practice: 401 points to a credential problem (missing, wrong format, expired), 403 points to a permissions problem (valid key, but insufficient scope or access level). Fix 401 by correcting the credential; fix 403 by adjusting the key's permissions or using an account with the right access level.

How do I find which credential n8n is actually using for a node?

Open the node in the workflow editor and look at the credential dropdown — the name shown is the credential n8n will use on execution. To see the stored values, go to Settings → Credentials, find the credential by name, and open it. The credential test button sends a real request and confirms whether the stored key is currently accepted by the API.

My API key works in Postman but the same request fails in n8n with 401. Why?

Compare the exact Authorization header Postman sends with what n8n sends. Common differences: Postman adds 'Bearer ' automatically when you select Bearer Token auth, while an n8n HTTP Request node configured with a raw header value may send the token without the prefix. Also check that Postman and n8n are hitting the same base URL — sandbox vs. production endpoints are a frequent source of this discrepancy.

How do I fix an expired OAuth token in n8n?

Open Settings → Credentials, find the OAuth2 credential, and click Reconnect or Re-authorize. This opens the provider's OAuth consent screen and exchanges a new set of tokens. If the Reconnect button is missing, delete the credential and recreate it from scratch — the OAuth flow runs automatically when you save a new credential. After re-authorizing, re-run the failed execution to confirm the new token works.

Can I test an API credential in n8n without running the whole workflow?

Yes. Open Settings → Credentials, find the credential, and click the Test button if one is available. This sends a lightweight authenticated request to the API — usually a GET to a profile or account info endpoint — and reports whether the credential is valid. Not all credential types have a test button; for those, add a temporary HTTP Request node configured with the same credential and run it in isolation.

Related Guides