← Integration Hub

Google Workspace (second)

Action requiredSetup requiredMOCK

Inbox 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

  1. A Google Cloud project with the Gmail and Calendar APIs enabled

    You are hereNot done yet
    Administrator (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 console
  2. OAuth consent screen configured

    Not done yet
    Administrator (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 console
  3. An OAuth 2.0 client of type "Web application"

    Not done yet
    Administrator (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 console

    Paste this exactly

    https://crm.gopaxx.de/api/integrations/google/callback

    Paste 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.

  4. Client ID and secret saved in PAXX

    Not done yet
    Administrator (once)In the Hub

    Paste both into the form below. They are shared by both account slots, stored once, and the secret is sealed before it reaches the database.

  5. Encrypted credential storage initialized

    Done
    Administrator (once)In the Hub

    Credentials 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.

  6. Sign in and approve the permissions

    Done
    YouIn the Hub

    On 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.

From the Web application client you created. Not a secret — Google sends it to the browser during consent — so it is stored in the clear and shown back to you, which is what makes a mismatch diagnosable.

Stored encrypted and never sent back to the browser. Used server-side only, to exchange the authorization code and to refresh tokens.

Only needed if a proxy rewrites paths so the URI PAXX generates is not the one Google should receive. Leave blank to use the callback URL shown above.

Secret values are sealed with AES-256-GCM before they reach the database and are never sent back to the browser, so a field that is set shows only that it is set. Changing one requires the owner role and is recorded in the audit log by key, never by value.

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 available

    Important, 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 Feed
  • Calendar

    readNot available

    Today's schedule merged across both accounts, attendees, RSVP state and conference links.

    Available once this provider is connected.

    Dashboard → Today/calendar
  • Attention rules

    readNot available

    Four 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 satisfied
    Administrator (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
  • OAuth consent screen configured

    Not satisfied
    Administrator (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
  • An OAuth 2.0 client of type "Web application"

    Not satisfied
    Administrator (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
  • Client ID and secret saved in PAXX

    Not satisfied
    Administrator (once)In the Hub

    Paste both into the form below. They are shared by both account slots, stored once, and the secret is sealed before it reaches the database.

    clientId
  • Encrypted credential storage initialized

    Satisfied
    Administrator (once)In the Hub

    Credentials 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

    Satisfied
    YouIn the Hub

    On 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.