Talk to our team

Documentation

✉️ Email Delivery

Documentation, reference material and tutorials for CRM-NG SMTP Email: setup guides for every mail service, troubleshooting, and one article per error message.

Error: invalid_grant: bad request (Gmail)

Updated

By Duane GarnerChief Executive Officer (CEO)
Summarize: Claude ChatGPT View Markdown
On this page

Google rejected the Gmail token request as malformed. Usually the server clock is wrong or the saved token belongs to another OAuth client.

This article is for sites using the Google / Gmail mailer where a send fails with invalid_grant and the words "Bad Request", without any mention of expiry or revocation.

The error as you see it

invalid_grant: Bad Request

Shown by the Google / Gmail mailer, in the failed-send banner, in Tools → Debug Events and in the Email Log.

What this error means

Before each send, the plugin asks Google for a fresh access token, using the refresh token saved when you authorized the account. "invalid_grant" means Google would not accept that refresh token; "Bad Request" means it did not even get as far as checking expiry. Google could not match the request to a grant it recognises. Unlike the expired-or-revoked case, the cause is often on your server or in the saved settings rather than in the Google account.

Common causes

  • The server clock is wrong. Google signs and checks requests with timestamps. A web server that is several minutes off can make every token request fail.
  • The Client ID or Client Secret changed after authorizing. If you pasted credentials from a different OAuth client, or created a new secret and deleted the old one, the saved refresh token no longer matches the client that is asking.
  • The site was migrated or restored from a backup that holds an old, already-replaced token.
  • The authorization did not finish. If the redirect back to WordPress was interrupted, a half-saved connection can remain.
  • The redirect address changed. Moving the site to a new domain or switching between http and https changes the Authorized redirect URI, and tokens created under the old address may be refused.

How to fix

  1. Check the server time

    Ask your host to confirm the server synchronises its clock (NTP). In WordPress, Settings → General shows "Universal time"; compare it with the real UTC time. A difference of more than a minute or two is a problem the host must fix.

  2. Confirm the client

    In the Google Cloud Console (https://console.cloud.google.com/), open APIs & Services → Credentials and select your OAuth client of type Web application. Compare its Client ID with the one saved in WordPress.

  3. Check the redirect address

    In CRM-NG SMTP → Settings → General, press Copy URL to clipboard next to Authorized redirect URI. Make sure exactly that address is listed under Authorized redirect URIs on the OAuth client in Google. Save in Google if you added it.

  4. Re-enter the credentials if needed

    If the Client ID differed, paste the correct Client ID and Client Secret (use Remove Client Secret first to replace a saved secret), then press Save Settings.

  5. Reconnect the account

    Press Remove OAuth Connection, then Allow plugin to send emails using your Google account, and approve the request with the sending account.

  6. Send a test

    Go to CRM-NG SMTP → Tools → Email Test, fill in Send To and press Send Email.

Verify it worked

The test page reports "Test email sent successfully! Check your inbox to confirm delivery." and the settings page shows Connected as with the right address. Check Tools → Debug Events after a few real emails have gone out to make sure no new invalid_grant entries appear.

Notes

  • Reconnecting fixes stale tokens, but not a wrong server clock. If the error returns minutes after reconnecting, the clock is the first thing to check.
  • Do not share one OAuth client between a live site and copies of it. Each copy that authorizes can disturb the others.
Go to Top