SendGrid API 401 in n8n: "unauthorized" vs "authorization required" vs "grant is invalid, expired, or revoked"

Short answer: a SendGrid 401 has several different messages, and the message depends on two things: whether a key reached SendGrid at all, and which endpoint you called. I sent requests with made-up keys and recorded what came back. No real key was used, and no email was sent.

The messages I got

Endpoint	No key	Fake key
GET /v3/scopes	401 "authorization required"	401 "unauthorized"
GET /v3/user/profile	not tested	401 "unauthorized"
POST /v3/mail/send (empty {} body)	401 "Permission denied, wrong credentials"	401 "The provided authorization grant is invalid, expired, or revoked"
GET /v3/nonexistent	not tested	401 "authorization required" (or 403 "access forbidden", see below)

All bodies look like {"errors":[{"field":null,"message":"..."}]}. The /v3/mail/send errors also had a help field set to null.

What I tested

On November 13, 2026 I sent requests to api.sendgrid.com with invented keys. I used three fake keys: a 69-character one shaped like SG.xxxx.yyyy, a short SG.FAKE.FAKE, and a string with no SG. prefix. The send request used an empty JSON body, so even a valid key would not have sent a message.

• The same fake key gets different wording on different endpoints. On the two GET endpoints it was "unauthorized", but on /v3/mail/send it was "The provided authorization grant is invalid, expired, or revoked". If you copy a message from a failing send node and search for it, remember that a profile or scopes check with the same key may say something else.
• "authorization required" meant two different things. With no key on /v3/scopes it appeared as 401. With a fake key on a path that does not exist, it also appeared as 401. So that message does not by itself prove that no key was sent.
• The key length and the SG. prefix did not change the result on real endpoints. The 69-character key, the short key, and the no-prefix string all got the same messages on /v3/scopes, /v3/user/profile and /v3/mail/send. Only on the nonexistent path did the no-prefix string get 403 "access forbidden" instead of 401. I do not know why, so treat that as an observation only.
• A malformed header gave 400, not 401. Authorization: Bearer with nothing after it, and Authorization: SG.FAKE without the word Bearer, both returned 400 with "authorization required" on /v3/scopes. Sending Authorization: Basic ... gave 401 "unauthorized".
• The EU host behaved the same. The same fake key against api.eu.sendgrid.com returned 401 "unauthorized". I could not test whether a real key from one region is rejected by the other.

What the docs say

The SendGrid authentication page says to send an Authorization header with a Bearer token, where the token is your API key, and that you can give a key specific permissions to limit what it can reach. It does not list the 401 messages above, so the table in this post is my own observation, not documented behavior. The n8n SendGrid credentials page says the credential takes one API key, created under Settings > API Keys, and suggests giving it Full Access.

Checklist when you see a SendGrid 401

1. Look at the endpoint first. "unauthorized" from a GET and "grant is invalid, expired, or revoked" from /v3/mail/send were the same fake key in my tests.
2. "Permission denied, wrong credentials" on send was what I got with no key at all. Check that the n8n credential is actually selected on the node and that a header expression is not empty.
3. Re-copy the key. A copied space or line break, a deleted key, or a key from another account are plausible causes of an invalid key, but I could only test fake keys, so I could not tell which cause produces which message.
4. Check the header form. It must be Authorization: Bearer YOUR_KEY. In my test, leaving out Bearer or the key gave 400.
5. Permissions. The docs say keys can be limited. n8n's page suggests Full Access. I did not test a real restricted key, so I do not know what a permission error looks like.
6. Never paste a real key in a public forum or issue.

The same "missing" versus "invalid" split shows up in other APIs. I wrote up Stripe API 401 and GitHub API 401 and 403 from the same kind of fake-key tests.

What I did not test

• No real SendGrid key was used. I did not see a successful response, a permission error for a restricted key, a sender-identity error, or a rate-limit response.
• Only three GET endpoints and one POST with an empty body were used. A valid message body was never sent.
• I did not test inside n8n. All requests were made with curl.
• This is one day of observation. SendGrid can change its messages.

Sources: SendGrid API authentication and n8n SendGrid credentials. Tables and message wording are from my own requests on November 13, 2026.