SendGrid

sendgrid the provided authorization grant is invalid

Authorization grant is invalid is a SendGrid 535 SMTP or 401 API auth failure. Set SMTP username to apikey, use a full-permission API key, and use TLS 1.2.

Updated Jul 1, 2026

The short answer

"The provided authorization grant is invalid, expired, or revoked" is the message SendGrid returns with a 535 SMTP (or 401 API) authentication failure. Despite the OAuth-sounding wording, it means SendGrid rejected your credentials. Fix it by setting the SMTP username to the literal string apikey, the password to a valid full-permission API key, and using TLS 1.2+.

SendGrid returns "535 Authentication failed: The provided authorization grant is invalid, expired, or revoked" (or a 401 Unauthorized on the Web API v3) when it rejects the credentials you presented. The OAuth-style phrasing is misleading: SendGrid SMTP and the v3 API authenticate with a single API key, not an OAuth authorization grant. The message simply means "the key you sent is not a valid, active, sufficiently-permissioned key."

What causes "the provided authorization grant is invalid" on SendGrid?

  • The API key is wrong, mistyped, or truncated. SendGrid API keys are ~69 characters and begin with SG.. A trailing space, a line break, or copying only part of the key will fail. The key is shown only once at creation — if you lost it you must create a new one.
  • The SMTP username is not apikey. For SMTP relay, the username must be the literal lowercase string apikey for every account — not your SendGrid login, email, or account name. The password is the full API key. Using your account username here is the single most common cause.
  • The key was revoked or its permissions are too narrow. A deleted/revoked key, or a "Restricted Access" key without Mail Send permission, is rejected. SMTP relay in particular needs a key with Full Access or at least Mail Send.
  • TLS below 1.2. SendGrid requires TLS 1.2+. A client (or an old .NET Framework / OpenSSL build) negotiating TLS 1.0/1.1 fails the handshake and surfaces as a 535. (Per RFC 4954, 535 5.7.8 is the standard "authentication credentials invalid" reply.)
  • Wrong host/port or a blocked port. SMTP host must be smtp.sendgrid.net. Valid ports are 587, 25, or 2525 (STARTTLS) and 465 (implicit TLS). A firewall/ISP blocking these can present as an auth/connection failure.

How do I fix it?

  1. Generate a fresh API key in SendGrid: Settings → API Keys → Create API Key, choosing Full Access (or a Restricted key with Mail Send enabled). Copy the entire SG.-prefixed string immediately.
  2. For SMTP relay, configure exactly:
  3. Host: smtp.sendgrid.net
  4. Port: 587 (or 465 / 2525 / 25)
  5. Username: apikey (literal)
  6. Password: your full API key (no quotes, no whitespace)
  7. For the Web API, send the key as a Bearer token:
Authorization: Bearer SG.xxxxxxxxxxxxxxxxxxxxxx
  1. Confirm TLS 1.2+ is enabled in your client/runtime. On .NET Framework, set ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;.
  2. Complete Sender Authentication (domain authentication or a verified single sender) so the key is allowed to send from your address.
  3. Isolate with a raw test using OpenSSL to rule out your app code:
openssl s_client -starttls smtp -connect smtp.sendgrid.net:587 -crlf

Then issue AUTH LOGIN with base64-encoded apikey and your key.

With Courier

If you send via Courier, this error means the API key saved in your SendGrid provider configuration is invalid or under-permissioned. Generate a new Full Access key in SendGrid and paste it into the SendGrid integration settings in the Courier dashboard, then re-send.

FAQ

Common questions

No. Although the wording comes from OAuth2's invalid_grant family, SendGrid SMTP and the v3 API authenticate with an API key, not an OAuth grant. The message is SendGrid's way of saying the API key (or SMTP credentials) you presented is invalid, expired, revoked, or lacks Mail Send permission.

One API, every provider

Stop debugging raw provider errors

Courier connects to your email, SMS, and push providers, handles retries and failover, and surfaces delivery errors in plain language.

Reply-code definitions per RFC 4954 (535 5.7.8). Last reviewed Jul 1, 2026. Courier is not affiliated with third-party providers; error behavior may vary by implementation.