Per-User Inbox Provisioning for Multi-Tenant Agent SaaS

Originally published at lumbox.co

If you're building an agent product — personal shopping agents, AI recruiters, autonomous SDRs — every end user will eventually need their own agent, and every agent needs its own inbox. The naive approach (one shared inbox, filter by user) collapses fast. Here's the pattern that scales.

The rule: one inbox per (tenant, agent) pair

For a user running 3 agents, you provision 3 Lumbox inboxes. Each has isolated state, its own OTP stream, its own webhook routing. Tenancy becomes a property of the inbox, not a filter on a shared stream.

async function provisionAgent(userId: string, agentConfig: AgentConfig) {
  const inbox = await lumbox.inboxes.create({
    displayName: `${userId}/${agentConfig.name}`,
    metadata: { userId, agentId: agentConfig.id },
  });

  await db.agents.create({
    userId,
    inboxId: inbox.id,
    address: inbox.address,
    config: agentConfig,
  });

  return inbox;
}

Webhook routing

One webhook endpoint on your side, Lumbox posts every received email with the inbox's metadata. You look up which tenant + agent by the userId in the metadata and dispatch accordingly. No filtering, no risk of cross-tenant leaks.

Custom domain per tenant

For pro-tier customers, let them bring their own domain. Lumbox supports multi-domain inbox provisioning under a single org — the inbox is created on @theirdomain.com, but your billing + usage aggregation stays on the single parent org.

Lifecycle

• Soft delete when a user pauses an agent. Keep the inbox; stop webhook routing.
• Hard delete when they churn. Lumbox purges the inbox and all history.
• Transfer supported via org migration — inbox stays, billing moves.

Billing

Lumbox's metering reports per-inbox usage. Roll it up to tenant-level for your own invoicing, or expose it in a per-user dashboard. No per-tenant infrastructure to run — it's all one API call. lumbox.co.