Google Workspace

Google Workspace mailboxes are connected by a super admin, once per domain. KALI then acts as the addresses on that domain. There is no per-person Google sign-in and no refresh token stored for those mailboxes. A person can also connect only their own Google Calendar; that path is narrower and is described below.

The Google app

How Workspace is authorized	Domain-wide delegation. A super admin adds KALI’s service account in the Admin console. Users are not asked to consent.
Client ID	105974321967114898365
Service account	[email protected]
Admin console	Domain-wide delegation. Security, Access and data control, API controls, then Manage domain-wide delegation, Add new.
What you paste	The client ID above, and the permission list in the next section, as one comma-separated line. One missing or extra permission and Google refuses every mailbox on the domain.
What you do not receive	The service account’s private key. It stays on KALI’s servers. The client ID is not a secret and cannot be used without the key and your Admin console grant.

A separate Google sign-in exists for one person’s calendar. That consent screen uses an OAuth client, not the client ID above. Its redirect is https://app.getkali.io/api/auth/google/callback. Match that client by the ID shown on the consent screen.

Permissions

Paste this exact line into the Admin console:

https://www.googleapis.com/auth/calendar.events,https://www.googleapis.com/auth/calendar.readonly,https://www.googleapis.com/auth/meetings.space.settings,https://www.googleapis.com/auth/meetings.space.readonly,https://www.googleapis.com/auth/gmail.modify,https://www.googleapis.com/auth/admin.directory.user.readonly

Scope	Why it is requested
calendar.events	Create, update, and delete the meeting invites KALI sends, as that mailbox.
calendar.readonly	Read the calendar so KALI can see the event, responses, and free/busy.
meetings.space.settings	Set the Google Meet room so guests can join without knocking.
meetings.space.readonly	Read who joined a Meet, and when.
gmail.modify	Read and send follow-up email from that mailbox, and match replies. This permission does not include permanently deleting mail while skipping Trash.
admin.directory.user.readonly	List users on the domain when mailboxes are connected in bulk, and read a display name. It does not change directory settings or passwords.

The one-person calendar sign-in requests only calendar.events, calendar.readonly, and meetings.space.settings, with offline access so KALI can refresh that person’s token. It does not include Gmail or the Directory API.

This Gmail permission covers the mailbox. Google does not offer a folder-only equivalent. A dedicated Workspace user is the way to keep follow-ups off a person’s primary inbox. Public addresses such as gmail.com cannot be connected this way.

What KALI reads and sends

• Invites. KALI creates and updates calendar events on the connected mailbox, including the Meet link and the guest list. It can also remove an event it created.
• Follow-ups. After someone accepts, sequence email is sent from that mailbox’s own address, so a reply lands in that inbox.
• Replies. KALI reads the inbox to match a reply to the lead it emailed. A real reply stops the rest of that sequence. Automatic out-of-office replies do not.
• Approval. AI-written follow-ups can be held until a person approves them. That switch is off until you turn it on, under Show-Up Sequences, Human approval. Template sequences are not held by that switch.
• Who can browse the mailbox. A customer user sees the conversation with a lead and can reply in it. A full folder browser (inbox, sent, spam, trash, drafts) is limited to KALI platform admins.

The grant is domain-wide, but KALI will act on a domain only after that domain is bound to your workspace. Binding is a DNS TXT record at _kali.yourdomain, or a KALI admin recording the domain after confirming it with you. One person signing in is not treated as proof that the workspace owns the domain.

Data handling

• Workspace mailboxes store no Google refresh token. KALI signs a short-lived token for the address it is about to use. Removing the Admin console entry stops every mailbox on the domain at once.
• A one-person calendar connection does store a refresh token, the same way the Outlook connection stores its tokens. Removing that connection in KALI deletes the stored token. Revoke the Google grant at myaccount.google.com/permissions as well.
• Message content that KALI keeps is stored with the lead, in the same database as the rest of the workspace. It is not purged on a short mailbox-only timer.
• AI drafts are generated for that lead’s sequence. Mailbox content is not used to train KALI’s own models.
• Request the DPA and current security reports from your KALI contact. They are not posted on this site.

Network and setup

Allow these names. KALI does not publish a static IP list.

• app.getkali.io for the app.
• accounts.google.com and oauth2.googleapis.com for Google sign-in and token exchange.
• www.googleapis.com for Calendar, Gmail, Meet, and Directory calls.
• admin.google.com for the super admin who adds the client ID. KALI does not sign in there.
• openrouter.ai when an AI draft is generated.

1. Sign in at admin.google.com as a super admin of the domain.
2. Open Security, Access and data control, API controls, Domain-wide delegation, Manage domain-wide delegation, Add new.
3. Enter client ID 105974321967114898365 and the permission list from above. Click Authorize. Google usually applies it within a minute and documents up to 24 hours.
4. Bind the domain to your KALI workspace with the DNS TXT record your account manager gives you, or ask them to record it after you confirm the domain.
5. Connect the mailboxes, add each sending signature, and leave sequences off until you are ready to turn them on.

To turn the domain off, delete that client ID from Domain-wide delegation. To turn off one person’s calendar sign-in, remove the connection in KALI and revoke it under their Google Account permissions.