SECURITY WARNING: Never run commands you don't understand. Always review code before execution. Use at your own risk.
API New Added 2 October 2026

Google API: Request had insufficient authentication scopes (403)

The token is valid, but it was minted without the OAuth scope this method needs. IAM roles can be perfectly correct and the call still fails. It is common on Compute Engine VMs whose service account was given narrow access scopes at creation, and with user tokens that were granted before a new scope was added to the app.

Quick fix

Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.

Quick fix
# Which scopes does the current token actually carry?
TOKEN=$(gcloud auth print-access-token)
curl -s "https://oauth2.googleapis.com/tokeninfo?access_token=$TOKEN" | jq .scope

# Local dev: log in again with the scope you need
gcloud auth application-default login \
  --scopes=https://www.googleapis.com/auth/cloud-platform

# VM: change access scopes (instance must be stopped)
gcloud compute instances set-service-account my-vm --zone europe-west2-a \
  --scopes=cloud-platform

# User OAuth: add the scope and make the user consent again

How to diagnose API errors

API integration errors are usually a contract mismatch: the client and the server disagree about authentication, encoding, size limits, or which version of the API is in play. Because most API clients swallow the response body and surface only the status code, the single highest-value debugging habit here is to log the full response, headers included, before you touch any code.

If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.

  1. Reproduce the failing call with curl -v outside your application. If curl succeeds and your client fails, the bug is in your client's header or serialisation layer, not on the server.
  2. Print the exact Authorization header being sent (redact the secret, keep the prefix). A missing Bearer  prefix and a trailing newline from an environment file are the two most common causes of a mystery 401.
  3. Check for an intermediate proxy. A 413 or 502 from nginx, Cloudflare or an API gateway looks identical to one from your application, but is fixed in completely different config.
  4. For webhooks, verify the signature against the raw request body. Any middleware that parses and re-serialises JSON before your handler runs will silently break HMAC verification.
  5. Confirm the API version. Deprecation errors and unexpected schema changes almost always trace back to a pinned version header that was never updated, or one that was never pinned at all.

Tools worth reaching for

  • curl -v
  • httpie
  • Postman/Bruno
  • mitmproxy
  • ngrok (for webhooks)

Authoritative references

Primary documentation for this error, worth reading before applying any fix in production.

cloud.google.com developers.google.com

Related API errors

See all 20 API errors →

Browse other categories

Something missing or wrong?

This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.