Fix Google Workspace API Permission Errors

What Does the "Insufficient Permission" Error Actually Mean?

When Google Workspace migration tools authenticate through a service account, they're asking Google's APIs for permission to act on behalf of your users, read their mail, calendars, contacts, and tasks, without logging into each mailbox individually. The "insufficient permission" or "403: The caller does not have permission" error means Google received the request but rejected it because something in that authorization chain is incomplete.

This is different from a login failure. You're not being told your credentials are wrong. You're being told that the credentials are valid, but they don't have the rights Google is asking for. That distinction matters, because it points you toward the Admin Console and Cloud Console, not toward retyping a password.

Common Causes of API Permission Errors in Google Workspace Migration

Most permission errors during authentication trace back to one of four places. Rarely is it more than one at a time, so working through them in order usually finds the culprit fast.

1. Required Google APIs Are Not Enabled

Before a service account can touch any mailbox data, the underlying APIs it depends on need to be switched on inside the Google Cloud project. For a full mail, calendar, contacts, and tasks migration, that means:

• Admin SDK API
• Gmail API
• Google Calendar API
• Google Tasks API
• Google People API

If even one of these is left disabled, calls that touch that specific data type will fail with a permission error, even though everything else about the setup looks correct. This is one of the easiest causes to miss, because the service account and delegation can be configured perfectly and the migration will still fail on, say, calendar data alone.

2. OAuth Scopes Don't Match What the Migration Tool Requests

Domain-wide delegation works by pairing a service account's Client ID with a specific list of OAuth scopes in the Admin Console. If the scopes you authorized don't match what the migration software is actually requesting, Google grants access to some data and blocks the rest. A typical read-access scope set looks like this:

• https://www.googleapis.com/auth/admin.directory.user.readonly
• https://www.googleapis.com/auth/gmail.readonly
• https://www.googleapis.com/auth/calendar.readonly
• https://www.googleapis.com/auth/tasks.readonly
• https://www.googleapis.com/auth/contacts.readonly

A single typo, an extra space, or a scope pasted into the wrong field is enough to break authorization for that data type, and Google won't tell you which scope was the problem. It just returns a permission error.

3. Domain-Wide Delegation Isn't Fully Authorized

Domain-wide delegation has to be granted at the domain level by a Super Administrator, not just created at the service account level in Cloud Console. If the Client ID was never added under ‘Security’ > ‘Access and data control’ > ‘API Controls’ > ‘Manage Domain-Wide Delegation’ in the Admin Console, or if it was added but the scopes were saved incorrectly, the service account technically exists but has no domain-level authority. Migration software will authenticate the service account itself without issue, then get rejected the moment it tries to impersonate a user mailbox.

4. Organization Policies Are Blocking Service Account Keys

Some organizations lock down service account key creation entirely, usually as a security default. If your account can create a service account but can't generate the JSON key needed to authorize it, the culprit is almost always one of these two organization policies:

• iam.managed.disableServiceAccountKeyCreation
• iam.disableServiceAccountKeyCreation

With either policy enabled, no user, including super admins and project owners, can generate a service account key. This one is easy to misdiagnose, because it doesn't look like a permission error on the surface. It looks like the "Create Key" button simply doesn't work.

Step-by-Step Fix in Google Admin Console and Cloud Console

Follow the steps in the order shown to avoid configuration issues and unnecessary troubleshooting.

1. Confirm every required API is enabled: In Google Cloud Console, go to APIs & Services > Library and check that Admin SDK API, Gmail API, Google Calendar API, Google Tasks API, and Google People API all show as Enabled, not just Available.
2. Verify the service account exists and copy its Client ID: Under IAM & Admin > Service Accounts, open the account being used for migration and note the numeric Client ID, not the email address. Domain-wide delegation is authorized by Client ID.
3. Check domain-wide delegation in Admin Console: Sign in as a Super Administrator, open Security > Access and data control > API Controls > Manage Domain-Wide Delegation, and confirm the Client ID is listed. If it's missing, add it with "Add New."
4. Re-enter the OAuth scopes exactly: Paste the full comma-separated scope list into the OAuth Scopes field rather than typing it manually, then click Authorize and Save. Even a trailing space can cause a mismatch.
5. Check the two key-creation policies if the JSON key won't generate: In Cloud Console, go to IAM & Admin > Organization Policies and search for both iam.managed.disableServiceAccountKeyCreation and iam.disableServiceAccountKeyCreation. If either is enforced, you'll need Organization Policy Administrator rights to override it at the project level and set enforcement to off.
6. Allow time for propagation: Domain-wide delegation and organization policy changes don't always apply instantly. Give it five to ten minutes before retrying authentication, particularly in larger domains.

For the full walkthrough with screenshots of every screen involved, see the Google Workspace Admin Configuration guide.

Re-Authenticating in EdbMails

Once the API, scope, and policy issues are resolved on the Google side, EdbMails needs to pick up the corrected credentials.

1. Download the fresh JSON key generated after fixing delegation and policies.
2. Open EdbMails and go back to the Google Workspace connection screen.
3. Remove the previously uploaded JSON key rather than layering a new one on top of it, since a stale key can still trigger authentication conflicts.
4. Upload the new key and re-enter your Workspace domain and admin email.
5. Run a test connection before starting or resuming the migration. EdbMails will validate access to the Admin SDK, Gmail, Calendar, Contacts, and Tasks APIs individually, so if one is still misconfigured, you'll see exactly which one failed instead of a generic error.

If authentication succeeds for some data types but not others, that's a strong signal you're still missing one specific API or scope rather than facing a broader account issue. Go back through steps 1 and 2 above with that data type in mind.

Preventing This From Happening Again

A few habits make repeat permission errors far less likely on future migrations or reruns:

• Keep a record of the exact API list and scope list used for the current project, since Google Cloud project settings don't carry over automatically if you create a new project later.
• Assign domain-wide delegation changes to a small, known group of Super Admins rather than letting multiple people configure it independently.
• Check organization policies before generating a new JSON key on any project, not just the first one.
• Run a small pilot migration, a handful of test mailboxes, before committing to a full domain migration. It surfaces permission gaps early, when they're a five-minute fix instead of a stalled production migration.

Authentication issues in Google Workspace migration are almost always fixable within Google's own console screens rather than anything in the migration software itself. Once the API list, scopes, delegation, and organization policies line up, re-authentication in EdbMails is a two-minute step, and the migration continues from wherever it left off.

---

Additional Resources:

• Google Workspace Admin Configuration for Migration
• Common Google Workspace Migration Issues and How to Fix Them
• Google Workspace to Office 365 Migration FAQs
• Migrate Google Workspace Without User Credentials
• Multifactor Authentication setup