DEV Community: Kumar Deepanshu

Per-User Inbox Provisioning for Multi-Tenant Agent SaaS

Kumar Deepanshu — Mon, 15 Jun 2026 18:00:05 +0000

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.

Web Bot Auth: Signing Outbound Agent Webhooks with HTTP Message Signatures

Kumar Deepanshu — Fri, 12 Jun 2026 18:00:29 +0000

Originally published at lumbox.co

Your SaaS sends webhooks. The receiver's endpoint is public. Anyone who discovers the URL can POST to it pretending to be you. Shared HMAC secrets are the common fix, but they require out-of-band key exchange and they don't rotate well. RFC 9421 HTTP Message Signatures — the "Web Bot Auth" pattern — is the better answer.

What Web Bot Auth gives you

You publish an Ed25519 public key at /.well-known/http-message-signatures-directory.
You sign outbound requests with the matching private key using the Signature-Input and Signature headers.
The receiver fetches your JWKS (once, cache it) and verifies every incoming request.

No shared secret. No one-to-one key exchange. Rotate by publishing a new kid in the JWKS.

The signature in practice

Signature-Input: sig1=("@method" "@target-uri" "content-digest" "date");\
    keyid="FOhe9v_YLODSykvK-u7VZ5K1-pI85ZN64swJn1YiLcQ";\
    alg="ed25519";\
    created=1749744000
Signature: sig1=:MEUCIQDX...:
Content-Digest: sha-256=:X48E9qOok...:
Date: Tue, 12 Jun 2026 12:00:00 GMT

Signing side (Node)

import { sign } from "http-message-signatures";

const signed = await sign(request, {
  key: privateKey,
  keyId: "FOhe9v_YLODSykvK-u7VZ5K1-pI85ZN64swJn1YiLcQ",
  alg: "ed25519",
  components: ["@method", "@target-uri", "content-digest", "date"],
});
await fetch(signed.url, { method: "POST", headers: signed.headers, body });

Verifying side

The receiver fetches your JWKS from /.well-known/http-message-signatures-directory, caches it, and runs the signature verification. Any tampered body, replayed request (outside the created window), or wrong keyid fails verification.

Why agents especially need this

When an AI agent receives a webhook from a third party, it has no way to know if the payload is legit unless the sender is cryptographically identified. Web Bot Auth is the pattern Cloudflare, Anthropic, and others are converging on for agent-to-agent trust. lumbox.co signs every outbound webhook with Ed25519 so your agent can trust what arrives.

OAuth for MCP Servers: Authenticating Agents, Not Humans

Kumar Deepanshu — Tue, 09 Jun 2026 18:00:20 +0000

Originally published at lumbox.co

The Model Context Protocol spec recommends OAuth 2.1 + Dynamic Client Registration (RFC 7591) for server authentication. In practice, 90% of MCP servers ship with static API keys. That works for single-user local setups. It breaks the moment you want to expose an MCP server to many agents, many users, or a public marketplace.

Why OAuth beats API keys for MCP

Scoped access. An agent can request inboxes.read but not inboxes.delete.
Revocable without rotating. A compromised token is revoked; the long-lived secret never leaves the server.
Per-user attribution. Every tool call has a user identity. Audit becomes possible.
Dynamic client registration. An MCP client (Claude, Cursor) can self-register without a human configuring the server.

The minimum viable OAuth surface

/.well-known/oauth-authorization-server — RFC 8414 metadata.
/.well-known/oauth-protected-resource — RFC 9728 linking resource to auth server.
/oauth/register — RFC 7591 Dynamic Client Registration.
/oauth/authorize — standard OAuth 2.1 authorization code flow with PKCE.
/oauth/token — token exchange.

Token design for agents

Short-lived access tokens (15 minutes), long-lived refresh tokens (30 days, rotating on use), narrow scopes per tool class. Don't issue a token with * scope unless the client literally needs every tool.

The Lumbox approach

Lumbox's MCP server is moving from API-key auth to full OAuth 2.1 + DCR. When an agent installs @lumbox/mcp-server, the client auto-registers, pops an OAuth consent screen once, and gets scoped tokens for the tools it asked for. No hand-editing a config file with a key. lumbox.co.

Event-Driven Email Agents with Inngest and Lumbox

Kumar Deepanshu — Sat, 06 Jun 2026 18:00:07 +0000

Originally published at lumbox.co

Inngest took the parts of writing a real application that always suck — queues, retries, cron, long-running jobs — and collapsed them into a single primitive: the event-driven function. It's the right partner for Lumbox, because inbound email is the event layer most agent backends are missing.

The wiring

Lumbox fires a webhook when mail arrives. Point that webhook at an Inngest event endpoint. Inngest's function handles the parsed email with full retry + observability.

// Point Lumbox webhook at: https://inn.gs/e/YOUR_INGEST_KEY
// Events emitted as "lumbox.email.received"

import { inngest } from "./client";

export const handleInboundEmail = inngest.createFunction(
  { id: "handle-inbound-email" },
  { event: "lumbox.email.received" },
  async ({ event, step }) => {
    const { from, subject, text, extracted } = event.data;

    if (extracted.otp) {
      await step.run("resolve-pending-signup", async () => {
        return resolvePendingSignup(from, extracted.otp);
      });
    }

    await step.run("log-to-crm", () => logEmail(from, subject, text));
  },
);

Scheduled follow-ups

Use Inngest's step.sleep to schedule a follow-up email in a day, a week, a month. Lumbox handles the send, Inngest handles the durability.

export const followUp = inngest.createFunction(
  { id: "follow-up" },
  { event: "signup.completed" },
  async ({ event, step }) => {
    await step.sleep("wait-3-days", "3d");
    await step.run("send-followup", () =>
      lumbox.inboxes.send(AGENT_INBOX, {
        to: event.data.email,
        subject: "How's it going?",
        text: "Checking in from your onboarding agent.",
      }),
    );
  },
);

lumbox.co.

Durable Email Workflows with Temporal and Lumbox

Kumar Deepanshu — Wed, 03 Jun 2026 18:00:34 +0000

Originally published at lumbox.co

Temporal solves the problem every async workflow eventually hits: what happens if the process dies mid-flow? For email, it's acute — you kick off a signup, the worker crashes, and now you have a Lumbox inbox waiting for an OTP that no one is listening for. Temporal activities make that durable.

The pattern: inbox creation as an activity

import { proxyActivities } from "@temporalio/workflow";
import type * as activities from "./activities";

const { createInbox, submitSignup, waitForOtp, submitOtp } =
  proxyActivities<typeof activities>({
    startToCloseTimeout: "5 minutes",
  });

export async function signupWorkflow(service: string, user: User) {
  const inbox = await createInbox(`signup-${service}`);
  await submitSignup(service, user, inbox.address);
  const otp = await waitForOtp(inbox.id, 120);
  await submitOtp(service, otp);
  return { success: true, address: inbox.address };
}

Long waits are fine

Some verification flows send a link that expires in 24 hours. Temporal can hold a workflow open for days with no resource cost — when the worker comes back, the state picks up. Lumbox inboxes don't expire unless you tell them to, so a workflow that sleeps for a day and then checks the inbox works exactly as expected.

Retries are automatic

If waitForOtp times out, Temporal retries per your activity policy. Lumbox's timeout is server-side — the HTTP call cleanly returns after the timeout window, and Temporal handles the rest. lumbox.co.

Mastra + Lumbox: TypeScript-First Agent Email in 30 Lines

Kumar Deepanshu — Sun, 31 May 2026 18:00:38 +0000

Originally published at lumbox.co

Mastra filled a gap: a genuinely good TypeScript framework for agents. LangChain.js never felt like a first-class citizen; Mastra does. Here's how to bolt Lumbox on in about 30 lines.

Defining email tools

import { createTool } from "@mastra/core";
import { Lumbox } from "lumbox";
import { z } from "zod";

const lumbox = new Lumbox({ apiKey: process.env.LUMBOX_API_KEY! });

export const createInbox = createTool({
  id: "create_inbox",
  description: "Create a fresh email inbox for a specific task.",
  inputSchema: z.object({ purpose: z.string() }),
  execute: async ({ context }) => {
    const inbox = await lumbox.inboxes.create({
      displayName: context.purpose,
    });
    return { inboxId: inbox.id, address: inbox.address };
  },
});

export const waitForOtp = createTool({
  id: "wait_for_otp",
  description: "Block until a verification OTP arrives.",
  inputSchema: z.object({
    inboxId: z.string(),
    timeout: z.number().default(120),
  }),
  execute: async ({ context }) => {
    const result = await lumbox.inboxes.waitForOtp(context.inboxId, {
      timeout: context.timeout,
    });
    return { otp: result.otp };
  },
});

The agent

import { Agent } from "@mastra/core";

export const signupAgent = new Agent({
  name: "signup_agent",
  instructions: "You sign users up for services. Use create_inbox, then wait_for_otp.",
  model: { provider: "anthropic", name: "claude-opus-4-7" },
  tools: { createInbox, waitForOtp },
});

Workflow orchestration

Mastra's workflows give you checkpointed, resumable flows. A signup that stalls at the OTP step can be resumed hours later — Lumbox keeps the inbox alive and the OTP retrievable. lumbox.co.

LlamaIndex + Lumbox: Treat Your Inbox as a Queryable Knowledge Source

Kumar Deepanshu — Thu, 28 May 2026 18:00:43 +0000

Originally published at lumbox.co

LlamaIndex made RAG something you can ship in an afternoon. Load docs into an index, attach an LLM, query. The gap most teams hit isn't the framework — it's finding a good data source. Your agent's own Lumbox inbox is a better source than most.

Why the inbox is good RAG fodder

It's high-signal, low-noise (it's already filtered by being sent to you).
It's structured — sender, date, subject, thread ID are all fields.
It grows organically as the agent does its work.

Wiring it up

from llama_index.core import VectorStoreIndex, Document
from lumbox import Lumbox

lumbox = Lumbox(api_key=os.environ["LUMBOX_API_KEY"])

def load_inbox_as_documents(inbox_id: str) -> list[Document]:
    messages = lumbox.inboxes.list_messages(inbox_id=inbox_id, limit=500)
    return [
        Document(
            text=m.text,
            metadata={
                "from": m.from_address,
                "subject": m.subject,
                "date": m.received_at,
                "thread_id": m.thread_id,
            },
        )
        for m in messages
    ]

docs = load_inbox_as_documents(my_inbox_id)
index = VectorStoreIndex.from_documents(docs)
query_engine = index.as_query_engine()
print(query_engine.query("What did Acme say about the Q3 timeline?"))

Keep it fresh with webhooks

Subscribe to Lumbox's email.received webhook and incrementally upsert new messages into the index. No re-indexing, no polling. lumbox.co.

AX (Agent Experience): What Email APIs Should Look Like for Agents, Not Humans

Kumar Deepanshu — Mon, 25 May 2026 18:00:38 +0000

Originally published at lumbox.co

Resend coined Agent Experience — AX — as the agent-first parallel to DX. The idea: APIs designed for humans reading docs on a Tuesday afternoon look different from APIs designed for LLMs calling tools in a tight loop. For email APIs, the gap is huge.

What bad AX looks like in email APIs

Polling required. Agent burns tokens checking "any new mail?" every 5 seconds.
Raw MIME. Agent has to parse multipart boundaries before it can read the body.
No first-class OTP field. Agent runs regex on HTML to find the code.
Opaque errors. Agent gets "500: internal error" with no recovery guidance.
No idempotency. Agent retries and sends duplicates.

What good AX looks like

Long-poll endpoints. One call, blocks until event or timeout.
Structured extraction. OTP, links, attachments, category — all as first-class JSON fields.
Typed errors. {"error": "timeout", "retryable": true, "wait_ms": 5000}.
Idempotency keys. Every mutating endpoint accepts one.
MCP-native. Tools are discoverable via a manifest, not scraped from HTML docs.
Machine-readable docs. OpenAPI + .well-known/agent-skills + llms.txt.

Lumbox's take

Every Lumbox endpoint was designed with a question: "how would a tool-calling LLM invoke this?" That's why waitForOtp exists instead of a listMessages + filter pattern. It's why responses include otp, links, and category alongside the raw body. It's why we publish an MCP server on day one.

AX isn't a checkbox. It's the shape of the whole API surface. lumbox.co.

Email as Memory for AI Agents

Kumar Deepanshu — Fri, 22 May 2026 18:00:18 +0000

Originally published at lumbox.co

Every agent framework now ships a memory module. Vectors, summaries, reflection loops, graph-based recall. They all miss the simplest and most reliable memory primitive on the internet: the email inbox.

What email gets right as memory

Append-only by default. You don't lose history.
Addressable. Every message has a stable ID and thread ID.
Searchable. Full-text search is built in.
Structured where it matters. Sender, subject, date, attachments — all first-class fields.
Pull model. The agent reads when it needs, not streaming 24/7.
Interoperable. The rest of the world writes to the inbox without you asking.

The agent-memory pattern

Give the agent an inbox. When the agent takes an action, send a record email to itself summarizing what it did. When it needs to recall, query the inbox. Lumbox's API gives you list, search, thread, and filter — the full memory surface.

// agent acts
await lumbox.inboxes.send(self.inbox_id, {
  to: self.address,
  subject: "[memory] signed up for stripe",
  text: "Account created with card ending 4242, verified at 14:22Z",
});

// later, agent recalls
const memories = await lumbox.inboxes.search(self.inbox_id, {
  subject: "[memory]",
  since: "2026-05-01",
});

When it beats a vector store

When you need verbatim recall, temporal ordering, and cross-agent handoffs. Vector stores excel at fuzzy semantic similarity. Inboxes excel at "what did I do last Tuesday and who did I talk to about it."

Hybrid is fine

Use the inbox for durable, addressable, audit-able memory. Use a vector store for similarity search over summaries. They complement each other. lumbox.co.

Pydantic AI + Lumbox: Type-Safe Email Tools for Agents

Kumar Deepanshu — Tue, 19 May 2026 18:00:05 +0000

Originally published at lumbox.co

Pydantic AI leaned into the one thing Python agent frameworks were missing: type safety at the tool boundary. Define a tool as a function with Pydantic-validated inputs and outputs, and the framework handles the LLM-side schema and the runtime-side coercion. It's the right shape for production agents.

Lumbox as Pydantic AI tools

from pydantic_ai import Agent
from pydantic import BaseModel
from lumbox import Lumbox

lumbox = Lumbox(api_key=os.environ["LUMBOX_API_KEY"])

class Inbox(BaseModel):
    inbox_id: str
    address: str

class OtpResult(BaseModel):
    otp: str
    received_at: str

email_agent = Agent(
    "anthropic:claude-opus-4-7",
    system_prompt="You handle email verification for signup flows.",
)

@email_agent.tool_plain
def create_inbox(purpose: str) -> Inbox:
    """Create a fresh inbox for a verification task."""
    inbox = lumbox.inboxes.create(display_name=purpose)
    return Inbox(inbox_id=inbox.id, address=inbox.address)

@email_agent.tool_plain
def wait_for_otp(inbox_id: str, timeout: int = 120) -> OtpResult:
    """Block until an OTP arrives in the inbox."""
    result = lumbox.inboxes.wait_for_otp(inbox_id, timeout=timeout)
    return OtpResult(otp=result.otp, received_at=result.received_at)

Why type-safe tools matter for email

When an agent calls wait_for_otp with a timeout, you don't want a runtime error because the LLM passed "60s" instead of 60. Pydantic coerces at the tool boundary. Same for inbox IDs — Pydantic ensures you always get a well-formed inbox_id, never None.

Error handling

If the OTP wait times out, the tool raises — Pydantic AI surfaces the typed error back to the agent, which can retry or escalate. Cleaner than parsing string error messages out of generic HTTP responses. lumbox.co.

Infraforge vs Lumbox: Deliverability-First vs Agent-Native Email

Kumar Deepanshu — Sat, 16 May 2026 18:01:06 +0000

Originally published at lumbox.co

Infraforge appears on most "best AgentMail alternatives" lists because it targets the deliverability-first segment of email infrastructure. Lumbox targets the AI-agent-first segment. Both valid, different focuses.

Infraforge's shape

Managed outbound email infrastructure — warming pools, IP rotation, reputation management.
Focused on cold outreach, transactional at scale, and B2B email workflows.
Strong on deliverability tooling, domain authentication, and sender analytics.

Lumbox's shape

Agent-native — every agent gets its own inbox.
OTP / magic-link / verification-link extraction built in.
Long-poll endpoints so agents don't waste tokens polling.
MCP server so Claude and Cursor can treat Lumbox as a tool out of the box.
BYOS: bring your own SMTP/domain when you want full deliverability control.

When they overlap

If you're running outbound-heavy agent workflows (cold outreach, mass notification), you need both: Lumbox for agent identity + inbox, and a deliverability layer (either Infraforge, SES with warm IPs, or Lumbox's BYOS mode with your own SMTP). The inbox side and the deliverability side are different problems.

When they don't

If you're running inbound-heavy flows — signups, verifications, agent-to-service interactions — Lumbox is the primitive. Deliverability is not the constraint; per-agent isolation and OTP extraction are. lumbox.co.

Unipile vs Lumbox: Unified Messaging API vs Agent-First Email

Kumar Deepanshu — Wed, 13 May 2026 18:01:12 +0000

Originally published at lumbox.co

Unipile and Lumbox show up together in "best email API for AI agents" listicles, but they're solving different problems. Here's how to tell which you actually need.

What Unipile does

Unipile is a unified communications API. One SDK, many channels — LinkedIn, WhatsApp, Instagram, Telegram, Gmail, Outlook, IMAP. You authenticate your users' accounts, then send and receive on their behalf across channels. Use case: building a multi-channel inbox product where end users connect their own accounts.

What Lumbox does

Lumbox provisions net-new email inboxes for AI agents. Every agent gets a fresh identity — not piggybacking on a user's Gmail, not sharing an account. Plus OTP extraction, long-poll, MCP server, and per-agent isolation. Use case: autonomous agents that need their own email to interact with the web.

Pick Unipile if...

You're building a product where end users connect their own accounts.
You need multi-channel reach (LinkedIn + WhatsApp + email).
You're building on behalf of humans, not agents.

Pick Lumbox if...

Your agent needs its own email identity, not a user's.
You need OTP/verification-link extraction out of the box.
You need long-poll endpoints so agents don't burn tokens polling.
You need per-agent isolation and fast lifecycle (create/destroy in seconds).

Can you use both?

Yes. A common pattern: use Unipile for the human-facing side of your product (LinkedIn DMs, WhatsApp replies) and Lumbox for the autonomous-agent side (signups, verifications, outbound to third-party APIs). Different problems, different tools. lumbox.co.