Connect Google Workspace

Wisteria’s AI ambient watcher reads documents from your shared Drives to propose training courses automatically. Connection uses Domain-Wide Delegation (DWD) — a single IT-admin task at setup, no per-employee installs.

What gets accessed

Wisteria’s service account is authorised to call these Google APIs on behalf of your domain:

All access is read-only. Wisteria never writes, modifies, or deletes anything in your Workspace.

Who can do this

You need a Google Workspace super administrator. Other admin roles cannot grant Domain-Wide Delegation.

If you’re not sure who your super admin is, log in at admin.google.com → Directory → Users → filter by Roles = Super Admin.

Setup steps

DWD setup has two parts: authorising at Google’s end, then confirming back in Wisteria.

Part 1 — Authorise Wisteria in Google Admin

1. Open the magic link sent to you by your Wisteria colleague. The landing page shows Wisteria’s Client ID and required Scopes.

2. Open admin.google.com in a new tab. Sign in as a super administrator.

3. Go to Security → Access and data control → API controls → Domain-wide delegation. (Some accounts may need to scroll past “Settings for less secure apps” to find this.)

4. Click Add new.

5. Paste:

   • Client ID → the value shown on the Wisteria magic-link page
   • OAuth scopes → the comma-separated list shown on the Wisteria magic-link page

6. Click Authorise.

That’s the Google side done.

Part 2 — Confirm in Wisteria

Back on the Wisteria magic-link page:

1. Enter your Primary domain (e.g. acmecorp.com — the domain your users sign in with).
2. Enter a Super admin email at that domain (e.g. admin@acmecorp.com). Wisteria will impersonate this user to test the connection.
3. Click Verify & finish setup.

Wisteria mints a token via Domain-Wide Delegation, makes a small test call against the Admin SDK, and confirms the setup works. The page redirects you to a “Thanks, all done” screen, and your colleague gets an email.

What if Verify fails?

”DWD not authorised yet” (or similar permission error)

Most common cause: the Client ID was pasted with a leading space or you authorised the wrong Client ID. Double-check the value in admin.google.com matches what’s shown on the Wisteria page exactly.

”User not found”

The super admin email you entered doesn’t exist at the domain. Check spelling.

”Insufficient permission” — 403

The user you’re impersonating is not actually a super admin. Use the email of someone with the Super Admin role at admin.google.com → Directory → Users.

”Google Cloud project not enabled for Admin SDK API”

Wisteria’s service account needs both the Drive API and Admin SDK API enabled. This is a one-time configuration on Wisteria’s Google Cloud project, not yours. Contact hello@getwisteria.com if you see this error.

Wrong domain

You can only DWD-authorise one Workspace at a time per Wisteria account. If you’ve previously connected a different domain, disconnect that first inside Wisteria.

Disconnecting

Two layers, like Microsoft 365:

1. Inside Wisteria — super_admin clicks Disconnect at Settings → Integrations → Google Workspace. Local row removed; watcher stops.
2. Inside Google Admin — at admin.google.com → Security → Domain-wide delegation, find Wisteria’s Client ID and click Remove. This revokes the underlying authorisation.

You can do either, both, or neither. Disconnecting at Wisteria is enough to stop the watcher; revoking at Google is the belt-and-braces option.

Why DWD instead of OAuth?

Two reasons:

1. Zero per-employee setup. OAuth requires every Drive user to click through a consent page. DWD authorises Wisteria’s service account once at the domain level — no individual approvals.
2. No token refresh dance. OAuth refresh tokens expire and need re-authentication. DWD impersonation tokens are minted server-side from the service-account private key with no user interaction.

The trade-off is DWD requires Google Workspace (not personal Google accounts). For per-user Drive access without DWD, the Google Drive connector under Settings → Integrations → Other connectors uses standard OAuth instead.

Security notes

• The private key for Wisteria’s service account lives only on Wisteria’s servers — never shared, never exposed in API responses.
• Wisteria impersonates the super admin you specified, not arbitrary users. The impersonation is logged at Google’s end.
• All API calls are read-only.
• If Wisteria ever rotates the service account, you’ll need to re-authorise at admin.google.com with the new Client ID. We’ll email you ahead of any rotation.

Coming back to verify

If you change your super admin email or rotate keys later, your super_admin can re-run verification from Settings → Integrations → Google Workspace → Re-verify inside Wisteria.