How to Handle 401 Unauthorized from OpenAI After Rotating Keys in n8n

Open the failed execution in n8n's Execution History. Click on the failed node (OpenAI, AI Agent, or HTTP Request). The error panel should show '401 Unauthorized' or 'Incorrect API key provided'. Check the timestamp — if the error started exactly when you rotated the key, it confirms the old key is still being used. Also verify the new key works by testing it directly with curl or the OpenAI Playground before troubleshooting n8n.

1# Test your new API key directly (outside n8n)
2curl -s -o /dev/null -w "%{http_code}" \
3  -H "Authorization: Bearer sk-your-new-key-here" \
4  -H "Content-Type: application/json" \
5  -d '{"model":"gpt-4o-mini","messages":[{"role":"user","content":"test"}],"max_tokens":5}' \
6  https://api.openai.com/v1/chat/completions
7# Should return 200

Go to the n8n main menu → Credentials. Find the OpenAI credential used by your failing workflows. Click on it to open the editor. Replace the API Key field with your new key. Click Save. Important: do not create a new credential — update the existing one. Creating a new credential requires you to update every node that references the old credential, which is error-prone. Updating in place ensures all nodes pick up the new key automatically once the cache is flushed.

n8n caches credentials in memory for performance. After updating a credential, you need to flush this cache. The method depends on your deployment: (1) Self-hosted: restart the n8n process. (2) n8n Cloud: deactivate and reactivate each affected workflow. (3) Any deployment: open each affected workflow, make a trivial edit (move a node slightly), and save. Saving triggers a credential re-resolution. For self-hosted Docker deployments, restart the container.

1# Self-hosted: restart n8n to flush all caches
2# Docker
3docker restart n8n
4
5# Docker Compose
6docker compose restart n8n
7
8# PM2
9pm2 restart n8n
10
11# Systemd
12systemctl restart n8n

If any of your workflows use the HTTP Request node to call OpenAI directly (instead of the built-in OpenAI node), the API key might be hardcoded in the Authorization header as a static value rather than referencing a credential. Search your workflows for HTTP Request nodes pointing to api.openai.com and check if the Authorization header uses a credential reference ({{ $credentials.openAiApi.apiKey }}) or a hardcoded key. Update any hardcoded keys to reference the credential instead, so future rotations only require one update.

1// Bad: hardcoded key in HTTP Request header
2// Authorization: Bearer sk-old-key-here
3
4// Good: credential reference in HTTP Request header
5// Use Header Auth credential type:
6// Name: Authorization
7// Value: Bearer (set in credential, not in node)

Before reactivating production workflows, run a manual test execution. Open one of the affected workflows, click 'Test Workflow' or 'Execute Workflow' to trigger a single execution. Check that the OpenAI node returns a successful response (200 OK). Inspect the execution output to confirm the response contains valid data. If the test still shows 401, the cache was not fully flushed — try a full n8n restart.

Implement a rotation procedure that minimizes downtime: (1) Create the new key in OpenAI before revoking the old one. (2) Update the n8n credential with the new key. (3) Flush the cache (restart or re-save). (4) Test with a manual execution. (5) Only then revoke the old key in OpenAI. This overlapping approach ensures there is never a moment when n8n has no valid key. For automated rotation, use n8n's API to update credentials programmatically.

1// n8n API: Update credential programmatically
2// POST /api/v1/credentials/{credentialId}
3// Use this in a separate n8n workflow triggered on a schedule
4
5// HTTP Request node configuration:
6// Method: PATCH
7// URL: {{ $env.N8N_BASE_URL }}/api/v1/credentials/{{ $json.credentialId }}
8// Headers:
9//   X-N8N-API-KEY: {{ $env.N8N_API_KEY }}
10// Body:
11// {
12//   "data": {
13//     "apiKey": "{{ $json.newApiKey }}"
14//   }
15// }