Use cases → Multi-tenant and agencies
Operate several Workspace tenants from one service account
Authorize the same client ID in each domain and switch tenants simply by changing who you impersonate.
| Who it is for | Agencies, holding companies and anyone running more than one Workspace domain. |
|---|---|
| APIs | Gmail API, Drive API, Calendar API |
| Typical scopes | varies per tenant |
The problem
A separate credential per tenant multiplies key handling, rotation and failure modes — and nobody remembers which key belongs to which client.
How it works
- Use one service account and authorize its client ID in each tenant's Admin console.
- Keep a per-tenant record of the scopes granted there.
- Select a tenant in code purely by choosing the subject to impersonate.
What changes
One credential, one rotation, and a clean mental model for which tenant you are acting in.
Questions people ask
Is one credential across clients acceptable?
It is a real trade-off. It simplifies operations and concentrates risk. Narrow scopes and strong key handling are what make it defensible.
Want this built?
This is a pattern we run in production. We will set up the delegation and build this on top of it — $500 per hour, most of it working the same day.
Talk to us Or read the setup guideRelated use cases
Produce per-client reporting from a shared estate
Generate and deliver each client's own report from data that lives across several tenants.
Run one automation estate across several brands
Share the machinery while keeping each brand's identity, sender and data cleanly separate.
Turn a finished meeting into follow-up automatically
Detect that a meeting happened, pull the notes, and draft the follow-up before anyone opens their laptop.