Workflow: Multi-Tenant Pods

Fresh 🌱

Pods isolate inboxes, domains, and API keys per tenant so one customer's data can never leak into another's. Build multi-tenant agent products with hard boundaries.

flowchart TD
    Org[Organization] --> PodA[Pod: Customer A]
    Org --> PodB[Pod: Customer B]
    PodA --> IA1[Inbox A1]
    PodA --> IA2[Inbox A2]
    PodA --> DA[Domain a.com]
    PodA --> KA[Scoped API key A]
    PodB --> IB1[Inbox B1]
    PodB --> DB[Domain b.com]
    PodB --> KB[Scoped API key B]

Pattern

1. Create a pod per tenant. POST /pods returns a pod_id.
2. Provision resources inside the pod. Inboxes, domains, drafts, threads, and API keys all have pod-scoped endpoints (/pods/{pod_id}/inboxes, /pods/{pod_id}/domains, etc.).
3. Issue a scoped API key per pod so your per-tenant agent code can only ever touch that tenant's data.
4. Query metrics per pod with /pods/{pod_id}/metrics/query for per-customer reporting.

Why pods

• Hard data isolation between tenants
• Per-tenant sending domains and reputation
• Per-tenant keys that limit blast radius if a key leaks

Related

Pods concept · Multi-tenancy · Pods API · Pods for multi-tenant (KB) · Permissions