Google Workspace (second)
Action requiredSetup requiredMOCKInbox summary, important mail and calendar for the personal account.
- How it connects
- Sign in with the provider
- Health
- healthy
- Integration status
- connected
- Credential
- Managed on its own settings tab
- Last sync
- never
- Connected
- not yet
2 of 6 steps done
Setup
A Google Cloud project with the Gmail and Calendar APIs enabled
You are hereNot done yetAdministrator (once)Provider console (one time)In console.cloud.google.com create (or pick) a project, then enable both the Gmail API and the Google Calendar API under APIs & Services → Library.
Open the provider's consoleOAuth consent screen configured
Not done yetAdministrator (once)Provider console (one time)Google Auth Platform → Audience and → Data access. "Internal" is enough for a Workspace domain and is strongly preferred: an External app in Testing has its authorizations — and therefore its refresh tokens — expire 7 days after consent, which is unusable for a daily driver. Add the six read-only scopes listed below. gmail.metadata is a RESTRICTED scope, so an External app in Production would additionally need Google verification plus a recurring third-party CASA security assessment; Internal avoids both.
Open the provider's consoleAn OAuth 2.0 client of type "Web application"
Not done yetAdministrator (once)Provider console (one time)Google Auth Platform → Clients → Create client. Add exactly the redirect URI shown here as an Authorized redirect URI — Google matches it byte-for-byte, including scheme, case and any trailing slash, and a mismatch produces an opaque error that never says which URI was sent.
Open the provider's consolePaste this exactly
https://crm.gopaxx.de/api/integrations/google/callbackPaste this exactly — the provider matches it byte-for-byte, including scheme, case and any trailing slash, and a mismatch fails at the provider with an error that never says which value it received.
Client ID and secret saved in PAXX
Not done yetAdministrator (once)In the HubPaste both into the form below. They are shared by both account slots, stored once, and the secret is sealed before it reaches the database.
Encrypted credential storage initialized
DoneAdministrator (once)In the HubCredentials are sealed with AES-256-GCM before they reach the database, and PAXX refuses to store them at all without a key. Initialize it with one click in the Integration Hub, or set the key in the server environment if you would rather manage it yourself. Google refresh tokens are the credential at stake here: without a key the consent flow would succeed at Google and then fail when PAXX tried to remember it.
Sign in and approve the permissions
DoneYouIn the HubOn the Google Workspace tab, press Connect for this slot. You will choose the account and approve the read-only permissions at Google — that consent screen is the approval step, and PAXX cannot complete the flow without it.
Once per deployment · owner only
Administrator configuration
Shared values every user of this PAXX instance connects through. Google Workspace (second) needs them before anyone can authorize an account, and they replace the environment variables an operator would otherwise have to set over SSH.
Sign in with the provider
Connect
Press Connect on the second slot, pick the Google account, and approve the six read-only permissions.
Setup required
In console.cloud.google.com create (or pick) a project, then enable both the Gmail API and the Google Calendar API under APIs & Services → Library.
callback URL to register: https://crm.gopaxx.de/api/integrations/google/callback
Live check
Connection test
A Gmail profile read (or a calendar list, for a Gmail-disabled account) using the stored token — refreshing it first if it has expired.
6 declared
Permissions
What PAXX asks the provider for. The provider's own consent screen is the authoritative grant — this list is what will be requested, and after connecting, what was actually returned.
- readSign-in identitynot grantedIdentifies which Google account granted access, so the two account slots can be told apart.
- readEmail addressnot grantedLabels which account is connected, so the two slots can be told apart.
- readName and profile picturenot grantedShows a recognisable identity instead of a bare email address.
- readGmail headers and labelsnot grantedSender, subject, timestamp, labels and thread structure. Google will not return message bodies or attachments under this scope.
- readList of your calendarsnot grantedShows which calendar an event came from.
- readCalendar eventsnot grantedToday's schedule, upcoming events, attendees and meeting links.
Capabilities
What you get
Inbox triage
readNot availableImportant, unread and recent mail per account, with sender, subject, labels and thread size. Metadata only — under gmail.metadata Google will not return a message body, so there is no preview line and nothing to read.
Available once this provider is connected.
Dashboard → Inbox/mailAttention FeedCalendar
readNot availableToday's schedule merged across both accounts, attendees, RSVP state and conference links.
Available once this provider is connected.
Dashboard → Today/calendarAttention rules
readNot availableFour deterministic rules — unanswered important mail, stalled threads, a meeting starting soon, and double-bookings across both accounts — each shown with the observation it fired on.
Available once this provider is connected.
Dashboard → Attention
Requirements
Diagnostics
Administrator requirements
One-time work for whoever administers this PAXX instance.
A Google Cloud project with the Gmail and Calendar APIs enabled
Not satisfiedAdministrator (once)Provider console (one time)In console.cloud.google.com create (or pick) a project, then enable both the Gmail API and the Google Calendar API under APIs & Services → Library.
OpenOAuth consent screen configured
Not satisfiedAdministrator (once)Provider console (one time)Google Auth Platform → Audience and → Data access. "Internal" is enough for a Workspace domain and is strongly preferred: an External app in Testing has its authorizations — and therefore its refresh tokens — expire 7 days after consent, which is unusable for a daily driver. Add the six read-only scopes listed below. gmail.metadata is a RESTRICTED scope, so an External app in Production would additionally need Google verification plus a recurring third-party CASA security assessment; Internal avoids both.
OpenAn OAuth 2.0 client of type "Web application"
Not satisfiedAdministrator (once)Provider console (one time)Google Auth Platform → Clients → Create client. Add exactly the redirect URI shown here as an Authorized redirect URI — Google matches it byte-for-byte, including scheme, case and any trailing slash, and a mismatch produces an opaque error that never says which URI was sent.
OpenClient ID and secret saved in PAXX
Not satisfiedAdministrator (once)In the HubPaste both into the form below. They are shared by both account slots, stored once, and the secret is sealed before it reaches the database.
clientIdEncrypted credential storage initialized
SatisfiedAdministrator (once)In the HubCredentials are sealed with AES-256-GCM before they reach the database, and PAXX refuses to store them at all without a key. Initialize it with one click in the Integration Hub, or set the key in the server environment if you would rather manage it yourself. Google refresh tokens are the credential at stake here: without a key the consent flow would succeed at Google and then fail when PAXX tried to remember it.
Your requirements
Per-person steps — the authorization is yours, not the deployment's.
Sign in and approve the permissions
SatisfiedYouIn the HubOn the Google Workspace tab, press Connect for this slot. You will choose the account and approve the read-only permissions at Google — that consent screen is the approval step, and PAXX cannot complete the flow without it.