Attach, send, and retrieve files through a single API. MultiMail handles storage, signed download URLs, and server-side malware scanning so your agent doesn't have to.
Attachments are a common failure point in agent-driven email systems. Files inflate request payloads, require separate storage backends, and introduce malware vectors that a naive API pass-through won't catch. Most teams bolt on S3, write custom MIME checks, and manually wire presigned URLs — none of which belongs in application logic. When an inbound email carries a .xlsx or a .pdf, the agent needs a safe, structured way to retrieve it without downloading raw bytes into memory or exposing a public URL.
MultiMail handles attachments inline on the send call and as structured metadata on inbound mail. To send a file, include it in the attachments array of your send request as base64 with a name and content type — MultiMail stores it and links it to the message. On inbound email, the message's attachment metadata (name, content type, size) is returned by the read endpoint, and each file is fetched on demand: download it directly, or request a short-lived signed URL that expires automatically so agents never have to hold raw bytes. The result is a consistent read/write pattern for files that works the same whether you're sending a report or parsing an inbound invoice.
Include each file in the attachments array of a POST /v1/mailboxes/{mailbox_id}/send call as { name, content_base64, content_type }. MultiMail stores it and links it to the outbound message. Multiple attachments map to multiple objects in the same array.
Inbound emails with attachments trigger an email.received webhook. Read the message via GET /v1/mailboxes/{mailbox_id}/emails/{email_id} to get structured attachment metadata for each file: name, content_type, and size. No binary data is inlined in the read response.
Fetch the bytes with GET /v1/mailboxes/{mailbox_id}/emails/{email_id}/attachments/{filename}, or request a short-lived signed URL with GET /v1/mailboxes/{mailbox_id}/emails/{email_id}/attachments/{filename}/url. The signed URL is valid for one hour — pass it to downstream tools, storage systems, or a human approver without granting permanent access.
Inbound mail is scanned (ClamAV) before it lands in the mailbox. Messages that fail scanning or score as spam are quarantined as a whole — the email status reflects the quarantine, so your agent can branch on it before processing any attachment.
Pick your platform, copy the prompt, and paste it to your AI agent — it sets up MultiMail and builds the whole flow. Nothing to fill in.
Inbound attachments live in MultiMail storage. Your agent works with metadata and short-lived signed URLs — it never has to hold raw inbound bytes in memory.
Inbound mail is virus-scanned (ClamAV) server-side, and messages that fail scanning or score as spam are quarantined as a whole before they reach your mailbox — not after your agent has already processed them. Content-type metadata is exposed so you can enforce your own type policy in the handler.
Outbound files go inline in the send call ({ name, content_base64, content_type }); inbound files surface as metadata on the read endpoint and are fetched on demand. One predictable pattern covers the full file lifecycle.
Request a signed URL for any inbound attachment by name; it is valid for one hour. Downstream tools, human approvers, and external systems get temporary access without permanent storage exposure.
Every inbound attachment surfaces with name, content_type, and size on the read endpoint. Your agent can make routing decisions on the metadata before ever fetching the file bytes.
Email infrastructure built for AI agents. Verifiable identity, graduated oversight, and a hosted MCP server. Formally verified in Lean 4.