Stripe API 401 in n8n: "You did not provide an API key" vs "Invalid API Key provided"

If a Stripe call from n8n or curl returns 401 with "You did not provide an API key" or "Invalid API Key provided: sk_test_****", the two messages point at different problems. I sent read-only requests to the Stripe API with made-up keys and recorded what came back. No real key was used, and nothing was created or changed.

The two 401 messages

Both bodies use type: invalid_request_error, so the type does not tell you which case you are in. The message does: "did not provide" means the request reached Stripe without a key, while "Invalid API Key provided" means a key arrived and Stripe did not accept it.

What I tested

On November 7, 2026 I sent GET https://api.stripe.com/v1/balance with fake values. Every key was invented.

• Stripe masks the key in the error, but keeps the prefix and the last four characters. That helps: you can check which key your workflow actually sent, and whether it starts with sk_test_, sk_live_ or something else, without exposing the full value in logs. Be careful pasting these messages publicly anyway, because the last four characters of a real key are still part of it.
• A fake key with a pk_ prefix got the same "Invalid" message as a fake secret key. I could not test a real publishable key, so I do not know whether Stripe words the error differently for a valid publishable key on a secret-only endpoint.
• Basic and Bearer behaved the same for the fake key. Only the www-authenticate header differed, and it followed the scheme I sent. For the no-key cases it always said Basic.
• A wrong path returned 404 before I could tell anything about the key. I sent a fake key there, so I cannot say whether a missing key on a bad path gives 404 or 401.

What the docs say

The Stripe authentication reference says the API uses HTTP Basic Auth with the API key as the username and no password, and that bearer auth works too (for example for cross-origin requests). It lists test mode secret keys as sk_test_, live mode secret keys as sk_live_, and restricted keys as rk_live_ in live mode. It also says requests without authentication fail and calls over plain HTTP fail.

The n8n Stripe credential page says the credential takes a Secret Key that starts with sk_, that test and live mode each have their own key (store them in separate credentials), that rk_ restricted keys are not tested with n8n, and not to use pk_ publishable keys.

Checklist when you see these errors

1. "You did not provide an API key": the key never reached the request. In an HTTP Request node, check that the credential is actually selected and that a header expression is not resolving to an empty string. My empty Bearer test gave exactly this message.
2. "Invalid API Key provided": compare the prefix and last four characters in the message with your dashboard key. Check for a copied space or line break, a key from the wrong mode, or a key that was rolled or deleted. I could only test fake keys, so I could not confirm which of these causes produces which wording.
3. Key type: use a secret key (sk_) in n8n, as the n8n page says. Do not paste a pk_ key.
4. Test versus live: objects in one mode are not visible from the other according to the n8n page, so a customer ID from live mode will not be found with a test key. I did not test that error.
5. Never paste a real key into a public issue or forum. The masked message from Stripe is safer to share than the key itself.

The same pattern ("missing" and "invalid" are different messages) shows up in other APIs too. I wrote up Cloudflare API token errors and GitHub API 401 and 403 from the same kind of fake-key tests.

What I did not test

• No real Stripe key was used. I did not see a successful response, a restricted-key permission error, a rolled or expired key, or a key from a closed account.
• Only GET /v1/balance was used. Other endpoints, POST requests, idempotency keys, and the Stripe-Account header for Connect were not tested.
• I did not test how this looks inside the n8n HTTP Request or Stripe node. All requests were made with curl.
• I did not test rate limits or webhook signature errors.
• This is one day of observation. Stripe can change its messages.

Sources: Stripe API authentication and n8n Stripe credentials. Response messages and the tables are from my own requests on November 7, 2026.