Guide: Multi-Tenancy
If you’re building a platform where each of your customers needs their own email infrastructure, this is how you set it up. The basic idea: create a Pod per customer, give them a scoped API key, and route webhook events to the right place.
Pods = Tenant Isolation
Every tenant gets their own Pod. All their resources (Inboxes, Domains, Threads, Drafts) live inside it and are completely isolated from other pods. Check out the Pods page for the full breakdown.
Then provision their resources:
Scoped API Keys
By default, API keys are organization-level and can access everything across all pods. Scoped API keys are restricted to a single pod. If a key is scoped to Acme’s pod, it can only touch Acme’s resources. Nothing else.
This is useful when you want to hand a key to a tenant’s service or agent without exposing your whole org.
The full API key is only returned once at creation. If you lose it, delete it and create a new one.
You can list and delete scoped keys for any pod:
Routing Webhook Events
You probably don’t want a single webhook catching events for every tenant. When creating a Webhook, you can scope it to specific pod_ids or inbox_ids so events only fire for the resources you care about.
Full Onboarding Flow
Here’s what onboarding a new tenant looks like end to end:
