Guide: Multi-Tenancy
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 restrict access to a single pod or a single inbox. 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.
Pod-scoped keys
Pod-scoped keys can access all resources within a pod (inboxes, threads, drafts, domains).
Inbox-scoped keys
Inbox-scoped keys are even more restrictive: they only grant access to a single inbox and its threads, messages, and drafts. Use these when an agent or integration only needs to operate on one address.
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 or inbox:
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:
