Register MultiMail as a function tool in any Assistant. Reads, sends, and replies route through configurable oversight modes before delivery.
The OpenAI Assistants API manages the orchestration layer for you — threads, run lifecycle, tool dispatch, and file context — so you can focus on what the assistant actually does. When that includes email, you need more than a raw SMTP credential attached to a function.
MultiMail exposes its full surface as JSON-schema function tools that register directly in an Assistant definition. The assistant calls check_inbox, send_email, or reply_email; MultiMail handles authentication, rate limiting, oversight gating, and delivery receipts before anything leaves your infrastructure.
Oversight mode is set per mailbox, not per call. An assistant operating in gated_send mode composes messages freely but every outbound send pauses for human approval via the MultiMail dashboard or webhook. The assistant never needs to know whether a given run required human review — the control plane is invisible to the model.
Because Assistants run server-side with persistent threads, inbound email is handled via webhooks that post to your server and optionally resume a Run with a tool output. MultiMail's inbound webhook delivers a structured payload — sender, subject, body, attachments — ready to pass directly into a thread as a tool result.
Define send, list-inbox, read, reply, and tag tools in your Assistant's tools array. A thin dispatcher in your run loop maps each tool call to the matching MultiMail route (the mailbox id goes in the path; the body uses fields like to and markdown), so wiring stays minimal.
The Assistants runtime controls when tools are called, but not what happens after. MultiMail's gated_send mode intercepts every outbound message at the API layer regardless of what the model decided, ensuring approvals can't be bypassed by prompt injection or unexpected tool chaining.
MultiMail webhooks deliver inbound messages as structured JSON. Your server can call submit_tool_outputs to feed the email into an active Run, continuing the thread without polling or background jobs.
Every email sent or received is logged with the thread ID, run ID, and assistant ID that triggered it. Audit trails map back to the exact conversation state that produced each outbound message.
Each assistant gets its own MultiMail API key scoped to specific mailboxes. A customer-support assistant cannot access the mailboxes provisioned for a billing assistant, even if both run under the same OpenAI organization.
No code, no dashboard. Paste this to your AI agent — it connects MultiMail, creates an inbox, and builds the flow for you.
Sign up at multimail.dev and provision a mailbox for your assistant. Set the oversight mode to gated_send to require approval on all outbound messages during development.
Add send_email and check_inbox to your Assistant's tools list. Use the JSON schemas that match MultiMail's request body format so tool arguments pass through without transformation.
Poll run status and intercept requires_action states. For each tool call, forward arguments to the corresponding MultiMail endpoint and collect the JSON response.
In the MultiMail dashboard, set an inbound webhook URL pointing to your server. MultiMail will POST structured email payloads on new delivery, which you can feed into active threads or use to trigger new runs.
With gated_send active, outbound messages appear in the MultiMail approval queue. Review and approve from the dashboard or via the API. Once approved, MultiMail delivers the message and your run continues.
Email infrastructure built for AI agents. Verifiable identity, graduated oversight, and a hosted MCP server. Formally verified in Lean 4.