Gmail
Connect Gmail to search and read email, send replies and forwards, draft messages, manage labels and filters, and keep the inbox triaged.
You end up pasting a Google OAuth Client ID and Client Secret from a Web application client you register in the Google Cloud console, with the three Gmail scopes added on its Data access page.
OAuth scope verification before this connector works
Every useful Gmail scope is classified restricted (mail.google.com, gmail.readonly, gmail.modify, gmail.compose, gmail.insert, gmail.metadata, gmail.settings.basic, gmail.settings.sharing), so Google must verify your OAuth client before it can leave Testing. Because a connector moves that data through a third-party server, Google additionally requires an annual CASA security assessment by a Google-empanelled assessor.
- Typical wait
- Google says restricted scope verification 'can potentially take several weeks to complete'. Brand verification alone is 2-3 business days. Recertification is required at least every 12 months from your assessor's Letter of Assessment approval date.
- Cost
- Google charges nothing for verification itself and publishes no price for the assessment. The CASA assessment is paid to a third-party App Defense Alliance assessor who sets its own fee; third-party writeups commonly report Tier 2 quotes in the mid-hundreds to low-thousands of USD per year, with Tier 3 and large-vendor engagements higher. Treat any specific figure as a quote to confirm with an assessor, not a list price.
- Blocked until approved
- Until verification lands the OAuth client stays in Testing publishing status: only hand-added test users can consent (the Cloud console caps this at 100), every one of them sees the unverified-app warning screen, and Google issues refresh tokens that expire in 7 days for External-type clients, so the connector dies with invalid_grant roughly weekly. You cannot onboard arbitrary end users at all.
- Works meanwhile
- Everything works fully for the hand-added test users, provided they re-consent weekly. Documented paths that skip verification entirely: an Internal-type app in a Google Workspace or Cloud Identity organisation, where restricted and sensitive scopes need no Google review (a service account with domain-wide delegation covers server-to-server Workspace mailbox access the same way); an app used only by yourself or a small group of people you know personally, which stays unverified and keeps the warning screen; and gmail.send alone, which is only a sensitive scope, so it needs standard verification (Google states 3-5 business days) and no CASA.
Where to apply: Google Cloud Console > Google Auth Platform (formerly APIs & Services > OAuth consent screen): complete Branding, verify domain ownership in Search Console, add the scopes under Data Access, then publish the app and submit for verification. Restricted scopes trigger a separate security-assessment request emailed to your listed contact; the assessment is booked through an App Defense Alliance authorised lab.
- Requesting a broader scope than you demonstrably need is the single most common rejection; ask for gmail.readonly rather than mail.google.com, or gmail.send if you only send.
- gmail.compose and gmail.metadata are restricted too, so 'we only draft' or 'we only read headers' does not avoid the assessment. Only gmail.labels and the add-on scopes are non-sensitive.
- The demo video must show the actual OAuth consent screen with the scope strings visible, then the in-app feature each scope powers. Videos that skip the consent screen are bounced.
- The privacy policy must be on the same verified domain as the app, be publicly reachable without login, and name Google user data and the Limited Use disclosure.
- Domain ownership must be verified in Search Console under the same account that owns the Cloud project.
- The assessment is annual. Missing recertification can suspend a live app's restricted-scope access.
- Switching the app back to Testing or editing scopes after approval can reset the review.
- Setup time
- 12 min
- Auth
- OAuth authorization
- API base URL
- https://gmail.googleapis.com/gmail/v1
- Rate limits
- Gmail API allows 1,200,000 quota units per minute per project and 6,000 quota units per minute per user per project, against a threshold of 80,000,000 quota units per day per project. Methods cost different amounts, with messages.list at 5 units and messages.send at 100.
Before you begin
- A Google account, plus a Google Cloud project you own (free, no billing card needed)
- Owner or Editor role on that Cloud project. Viewer cannot create OAuth clients
- The PopMCP callback URL from the Gmail connect form. Copy it before you start
- Willingness to publish the app. An External app left in Testing gets a refresh token Google expires after 7 days, and all three Gmail scopes here are restricted
- Personal Gmail accounts can only use the External audience. Internal requires a Google Workspace organisation
Get your credentials
Create a Cloud project and enable the Gmail API
Pick or create a project in the Cloud console, then go to APIs & Services → Library and search for Gmail API. Open its card and click Enable.
Fill in the consent screen under Google Auth Platform
Open Google Auth Platform → Branding and enter App name, User support email and a developer contact address, then click Save. Choose External as the user type unless everyone using this connector sits inside your Workspace organisation.
Add the three Gmail scopes on Data access
Go to Data access and click Add or remove scopes. Paste https://mail.google.com/, https://www.googleapis.com/auth/gmail.settings.basic and https://www.googleapis.com/auth/gmail.settings.sharing into the Manually add scopes box, click Add to table, then Update and Save.
Data access
Scopes define the permissions your app requests from users.
| API | Scope | User-facing description | Type |
|---|---|---|---|
| Gmail API | https://mail.google.com/ | Read, compose, send, and permanently delete all your email from Gmail | Restricted |
| Gmail API | .../auth/gmail.settings.basic | See, edit, create, or change your email settings and filters in Gmail | Restricted |
| Gmail API | .../auth/gmail.settings.sharing | Manage your sensitive mail settings, including who can manage your mail | Restricted |
All three must appear under Your restricted scopes before you save.
Publish the app on the Audience page
Open Audience and check Publishing status. If it reads Testing, click Publish app and confirm.
Audience
Choose who can authorize your app to access their Google Account data.
- User type
- External
- Publishing status
- Testing
Publishing needs no Google review. It adds a one-time unverified-app screen at consent.
Create a Web application OAuth client
Click Clients → Create client and set Application type to Web application. Under Authorized redirect URIs click Add URI, paste the callback URL from PopMCP's Gmail connect form exactly as shown, then click Create.
Create OAuth client ID
A client ID identifies your app to Google's OAuth servers.
Leave Authorized JavaScript origins empty. The code exchange happens server-side.
Copy the client ID and secret into PopMCP
Copy Client ID and Client secret from the OAuth client created dialog into PopMCP's OAuth Client ID and OAuth Client Secret fields. If the dialog is already gone, open the client and click Add secret.
Clients
Google hashes the secret. After this dialog only the last four characters are shown.
Connect in PopMCP
Open your workspace, choose Gmail in the marketplace, and fill in the connect dialog:
| Field | What to enter |
|---|---|
| OAuth Client IDtext | Google Cloud Console → Google Auth Platform → Clients → Create client → Web application, with the callback URL above under Authorized redirect URIs. Enable the Gmail API on the same project first (APIs & Services → Library → Gmail API → Enable), or the Gmail permissions won't be offered. |
| OAuth Client Secretsecret | Shown once, in the popup right after you create the client. Google hashes it and never shows it again; if you closed that popup, open the client and add a new secret. Stored encrypted here and used server-side only. TWO THINGS TO CHECK FIRST: (1) In Google Auth Platform → Data access, add all three Gmail scopes — https://mail.google.com/, gmail.settings.basic and gmail.settings.sharing. (2) In Google Auth Platform → Audience, if the status says "Testing", click "Publish app". Testing-mode apps get a refresh token Google expires after exactly 7 days, so the connection would work for a week and then stop. Publishing needs no Google review; it only adds a one-time "Google hasn't verified this app" screen where you click Advanced and continue.Encrypted with AES-256-GCM on save and never shown again. |
https://app.popmcp.com/api/providers/google/callbackPopMCP verifies the credential against Gmail immediately. On success the connection flips to Verified and its MCP tools are provisioned.
Permissions PopMCP requests
These are the scopes sent to Gmail at authorization time.
| Scope | Why PopMCP asks for it |
|---|---|
| https://mail.google.com/ | Full mailbox access for reading threads, sending, replying, forwarding and managing drafts and labels. Google classes it as restricted, which is what triggers the unverified-app warning. |
| https://www.googleapis.com/auth/gmail.settings.basic | Needed for the filter, label and vacation-settings tools. Also a restricted scope, despite only touching settings. |
| https://www.googleapis.com/auth/gmail.settings.sharing | Needed for send-as aliases and forwarding addresses. It is restricted, so it must be listed on Data access before consent will offer it. |
Verify it worked
In PopMCP, click Connect, choose the Google account, pass the "Google hasn't verified this app" screen via Advanced → Go to (app), and tick all requested Gmail permissions. The connector shows Connected and a message-search tool returns real threads from the inbox.
Troubleshooting
Error 400: redirect_uri_mismatch
Why: The Authorized redirect URI does not byte-for-byte match the callback URL PopMCP uses.
Fix: Re-copy the callback URL from the PopMCP connect form into Clients → your client → Authorized redirect URIs and save. Allow a couple of minutes to propagate.
invalid_grant after about a week
Why: The app is still in Testing, so Google expires the refresh token seven days after consent.
Fix: Go to Google Auth Platform → Audience → Publish app, then reconnect in PopMCP.
The consent screen never asks for the settings permissions
Why: gmail.settings.basic and gmail.settings.sharing were not added on the Data access page.
Fix: Add both scopes under Data access → Add or remove scopes → Manually add scopes, click Update and Save, then disconnect and reconnect so consent is re-requested.
Scopes do not appear in the picker on Data access
Why: Only scopes belonging to enabled APIs are listed, and the Gmail API is off on this project.
Fix: Enable Gmail API under APIs & Services → Library, then reopen Data access.
429 or 403 rateLimitExceeded during a large sync
Why: The ceiling of 6,000 quota units per minute per user per project was hit. A single messages.send costs 100 units, so bulk work burns through it quickly.
Fix: Let the connector back off and retry. Spread bulk operations out rather than requesting a full mailbox scan at once.
Reference
Fireflies
Connect Fireflies to search meetings, read summaries and action items, pull transcripts, share recordings, and send the notetaker into live calls.
Google Calendar
Connect Google Calendar to see what is coming up, book and reschedule meetings, add Google Meet links, check who is free, and manage sharing.