Cloudflare API in n8n: 400 "Missing Authorization header", 401 "Invalid API Token" and 403 "Invalid access token" (9109)

If a Cloudflare API call from n8n fails with 400, 401 or 403 and the body mentions a token, do not assume one code means one thing. In my tests the same made-up token got 401 with code 1000 on one endpoint and 403 with code 9109 on another, and a missing header got a 400, not a 401. Here is what I observed and a short checklist.

The four responses

What I tested

On 2026-11-06 I sent read-only GET requests to api.cloudflare.com/client/v4 with curl, using made-up credentials only. I never used a real token.

• The status code and the error code depend on the endpoint. One token, two endpoints, two different answers (401 and 403). If you only look at the status, an invalid token can look like a permissions problem.
• A missing header was a 400. If your workflow retries only on 401 or 403, this one will slip through.
• Every response had "success": false and an errors list with a code and a message, so those fields are the place to read the cause.
• The old key pair was rejected for its format, which suggests that Cloudflare checks the format first. I did not test a key that was well formed but wrong.

What the documentation says

The Cloudflare page on creating a token shows the token sent as Authorization: Bearer and says to use the /user/tokens/verify endpoint to fetch the current status of a token. A successful response there shows a status of active. The troubleshooting page tells you to check that the token is verified, to review its permission groups, and to use the Bearer option rather than the email and key pair.

Neither page lists the error codes 1000, 9109, 1001, 6003 or 6103, so what each code means above comes from my own requests, not from the documentation.

A short checklist

1. Verify the token first. Call the verify endpoint with the same token. If it does not report the token as active, fix that before anything else.
2. 400 with 1001: no Authorization header arrived. Check that the credential is attached to the node and that the header is spelled correctly.
3. 401 with 1000 or 403 with 9109 and a made-up or old token: the token was not accepted. Create a new token and replace it. I only tested made-up tokens, so this is a possible cause, not a tested result.
4. A 403 with a real token may point to permissions instead. The documentation says to review the token's permission groups. I did not test a real token with too few permissions.
5. Use the Bearer token option, not the old email and key pair, unless you have a reason not to.

A request to verify your own token looks like this. I did not run it with a real token, so I cannot show the successful response.

curl -H "Authorization: Bearer YOUR_API_TOKEN" \
https://api.cloudflare.com/client/v4/user/tokens/verify

Keep the token in the n8n credential and out of workflow files, chat messages and forum posts. If you saw similar patterns with other services, I wrote up the GitHub API and Gemini API cases the same way.

What I did not test

• I did not use a real token, so I did not see a permissions error, an expired token or a successful response.
• I tested only the verify endpoint and the zones list. Other endpoints may answer differently, as these two already did.
• Cloudflare Tunnel tokens are a separate thing, and I did not test them.
• I used curl, so I did not look at how n8n shows these errors, and I did not test rate limits.

Sources: Cloudflare documentation, create API token and API troubleshooting. The responses above come from my own requests on 2026-11-06.