How to set up API access to Google Workspace (Gmail and Drive)
Google Workspace does not hand out a single all-purpose API key. To let a developer or a connected tool read your Gmail messages or Google Drive files programmatically, you set up access through the Google Cloud console: you create a project, turn on the APIs you want (such as the Gmail API and the Google Drive API), set up the consent screen, and then create a credential. For most one-off integrations that is an OAuth client (the connecting app shows a Google sign-in screen and you authorise read-only access for your own account). For a shared mailbox or for accessing many accounts across your domain, an administrator instead creates a service account and grants it domain-wide delegation for specific read-only scopes. Either way you are only granting the access the scopes describe, and you can revoke it at any time. This guide is a little longer than most because Google has more moving parts, but each step is short.
Keep this credential safe
An OAuth client secret and a service-account JSON key are like passwords: anyone who holds them, together with the access you have authorised, can read the data the scopes allow. Always scope credentials to read-only where the product allows it (use gmail.readonly and drive.readonly rather than full-access scopes), grant domain-wide delegation only for the exact scopes needed, and share the secret or key file through a secure method such as a password-manager share link, never plaintext email or chat. Delete or rotate the credential as soon as it is no longer needed.
Access to grant
An OAuth 2.0 client (client ID and client secret) for accessing your own account, or a service account with domain-wide delegation for a shared mailbox or whole-of-domain access. Scopes limited to read-only, e.g. https://www.googleapis.com/auth/gmail.readonly and https://www.googleapis.com/auth/drive.readonly.
Who you're granting access to
- The developer, consultant, or tool that will read your Gmail or Google Drive data through the API.
Before you start
- A Google account that can use the Google Cloud console. For company data you usually want a Google Workspace account rather than a personal Gmail account.
- To create a service account with domain-wide delegation (for a shared mailbox or whole-of-domain access), you need a Google Workspace super administrator. The OAuth client route below works without admin rights for your own account.
- Agreement on exactly which read-only scopes are needed, for example Gmail read-only, Drive read-only, or both.
Step by step
- 1
Sign in to the Google Cloud console
Go to console.cloud.google.com and sign in with the Google account that should own this access. For business data, sign in with your Google Workspace account so the integration sits under your organisation rather than a personal Gmail account.
- 2
Create a project
A project is the container that holds your APIs and credentials. From the Menu, choose IAM & Admin, then Create a Project. Give it a clear name such as "Data integration", optionally pick a Location (your organisation), then click Create. Wait a few moments for the project to be ready and make sure it is selected in the project picker at the top.
- 3
Turn on the Gmail and Drive APIs
From the Menu, choose APIs & Services, then Library. Search for and open "Gmail API" and click Enable, then go back and do the same for "Google Drive API". Only enable the APIs the integration actually needs. Enabling an API does not grant access to your data by itself; the credential and its scopes do that.
- 4
Set up the consent screen (Google Auth platform branding)
From the Menu, choose Google Auth platform, then Branding, and click Get Started if prompted. Enter an App name and a User support email, click Next, then under Audience choose Internal if everyone using this is in your Google Workspace organisation (recommended for internal tools), or External if not. Add a contact email, agree to the user data policy, and finish. Internal apps avoid Google’s verification process and keep access inside your organisation.
- 5
Option A - Create an OAuth client (for your own account)
Use this for a single integration that reads your own mailbox or Drive. From the Menu, choose Google Auth platform, then Clients, and click Create Client. Pick the Application type your developer or tool tells you to use (commonly Web application or Desktop app), give it a name, add any redirect URI the tool provides, then click Create. Google shows the Client ID and, for most types, a Client secret.
- 6
Copy or download the OAuth client details
Copy the Client ID and Client secret, or use Download to save the JSON file. Treat the secret like a password: anyone with the client secret plus an authorisation can act with the access you granted. Share it only through a secure method such as a password-manager share link, never plaintext email or chat. When the connected tool runs, it will show a Google sign-in and consent screen where you approve the read-only scopes for your account.
- 7
Option B - Create a service account (for a shared mailbox or whole domain)
Use this when a tool needs to read a shared mailbox or many users’ data without a person signing in each time. From the Menu, choose IAM & Admin, then Service Accounts, and click Create service account. Give it a name and click Create and continue, then Done. Open the service account, go to the Keys tab, click Add key, then Create new key, choose JSON, and click Create. A JSON key file downloads once; this file is a credential, so store it securely and never commit it to code or email it in plaintext.
- 8
Grant domain-wide delegation for read-only scopes (admin)
A service account only reaches user data once a super administrator authorises it. In the Google Admin console (admin.google.com), go to the Menu, then Security, then Access and data control, then API controls, and click Manage Domain Wide Delegation. Click Add new, paste the service account’s Client ID, and in OAuth scopes enter only the read-only scopes you need, separated by commas, for example https://www.googleapis.com/auth/gmail.readonly,https://www.googleapis.com/auth/drive.readonly. Click Authorise. Keeping the scopes read-only means the tool can view data but not change, send, or delete anything.
Removing access afterwards
- To revoke an OAuth client: go to the Menu, then Google Auth platform, then Clients, open the client, and delete it. You can also remove a tool’s access for your account at myaccount.google.com under Security, then "Your connections to third-party apps and services".
- To revoke a service account: go to the Menu, then IAM & Admin, then Service Accounts, open the account, and either delete a specific key under the Keys tab (to rotate it) or delete the whole service account (to remove it entirely).
- To revoke domain-wide delegation: in the Admin console, go to Security, then Access and data control, then API controls, then Manage Domain Wide Delegation, and delete the entry for that Client ID. Access ends straight away.
If that option is not available
If you would rather not set up API access yourself, you can do the Google Cloud steps together on a screen-share call so the developer guides you and never sees a password. For a shared mailbox, a one-off export (for example Google Takeout, or a scheduled read-only report) may be enough, which avoids creating standing API credentials at all.
Frequently Asked Questions
Not for Gmail or Drive data. Simple API keys only work for public, non-user data. To read your own mailbox or Drive you create an OAuth client; to read a shared mailbox or whole-of-domain data you create a service account with domain-wide delegation. Both control access through scopes you choose.
An OAuth client is best when the integration reads your own account: you sign in and approve read-only access on a Google consent screen. A service account with domain-wide delegation is best for a shared mailbox or many users, and it needs a Google Workspace super administrator to authorise it. Use the OAuth client unless a shared or whole-of-domain mailbox is genuinely required.
Treat the OAuth client secret and the service-account JSON key like a password. Limit them to read-only scopes, store them in a password manager or secrets vault, and share them only through a secure password-manager link rather than plaintext email or chat. Never put a key in code, screenshots, or a shared document, and delete or rotate it when the work is finished.
Choose read-only scopes such as https://www.googleapis.com/auth/gmail.readonly and https://www.googleapis.com/auth/drive.readonly when configuring the consent screen or domain-wide delegation. These let a tool view your messages or files but not send, edit, or delete anything. Avoid broader scopes like the full Gmail or Drive scopes unless a task truly needs them.
Delete the OAuth client under Google Auth platform, then Clients, or remove the connection at myaccount.google.com under Security. For a service account, delete its key or the whole account under IAM & Admin, then Service Accounts, and remove its entry under Manage Domain Wide Delegation in the Admin console. Access ends immediately.
For the OAuth client route reading your own account, no. For a service account with domain-wide delegation that reaches a shared mailbox or other users’ data, a Google Workspace super administrator must authorise the service account’s Client ID and scopes in the Admin console.
Related guides
Steps last checked against Google Workspace on 2026-06-09.
Based on official Google Workspace documentation: Google for Developers: Create access credentials, Google for Developers: Create a Google Cloud project, Google for Developers: Enable Google Workspace APIs, Google for Developers: Configure the OAuth consent screen, Google for Developers: OAuth 2.0 Scopes for Google APIs. Google Workspace is a trademark of its respective owner; this guide is independent and for instruction only.
Want this handled for you?
Clever Ops connects and automates the systems mid-market businesses already run. Book a free assessment and we will map your stack.