Use MultiMail's REST API from Make's HTTP module to send, read, and approve emails with full audit trails — without writing a backend.
Make (formerly Integromat) lets teams build complex automation workflows by connecting SaaS tools through a visual scenario editor. When those scenarios involve sending email — especially email triggered by AI logic, CRM events, or webhook payloads — you need more than a simple SMTP relay. You need audit trails, delivery tracking, and the ability to require human approval before a message goes out.
MultiMail integrates with Make through its REST API via Make's native HTTP module. Any scenario can call MultiMail endpoints to send email, check an inbox, read a thread, tag messages, or trigger the `decide_email` approval flow — all with Bearer token authentication and structured JSON responses that map cleanly to Make's data mapping layer.
The combination is especially useful for teams running AI-assisted outreach, support escalations, or approval-gated notifications. Make handles the trigger logic and routing; MultiMail handles delivery governance, oversight mode enforcement, and the human-in-the-loop approval queue.
Set a mailbox to `gated_send` or `gated_all` oversight mode. Any HTTP POST to `send_email` from your Make scenario queues the message for human approval instead of sending immediately. Your scenario continues; the email waits. MultiMail fires a webhook to a separate Make trigger when the approver acts.
The `check_inbox` and `read_email` endpoints return clean JSON — sender, subject, body text, thread ID, tags. Make's data mapper can route fields directly into Airtable rows, Slack messages, or CRM updates without regex parsing or fragile HTML scraping.
Every send, read, approval, and rejection is logged against the mailbox. For teams subject to CAN-SPAM, GDPR Article 5 accountability requirements, or internal SOC 2 controls, this log is the audit trail that proves governed operation — not just that email was sent.
MultiMail fires an `inbound` webhook when a message arrives at your mailbox. Drop a Webhooks module at the start of a Make scenario to parse the payload and branch on sender, subject, or tags — no polling loop needed.
A mailbox used for high-volume notifications can run `monitored` while the same tenant's customer-facing mailbox stays `gated_send`. Switch modes via the API when a scenario's risk profile changes, without redeploying anything.
{
"url": "https://api.multimail.dev/v1/send_email",
"method": "POST",
"headers": [
{
"name": "Authorization",
"value": "Bearer $MULTIMAIL_API_KEY"
},
{
"name": "Content-Type",
"value": "application/json"
}
],
"body": {
"type": "raw",
"content": {
"mailbox_id": "[email protected]",
"to": "{{1.email}}",
"subject": "{{1.subject}}",
"body": "{{1.message_body}}",
"metadata": {
"make_scenario_id": "{{scenario.id}}",
"triggered_by": "crm_event"
}
}
}
}Configure Make's HTTP > Make a request module to call `send_email`. Map subject and body from upstream modules using Make's data mapper syntax.
"cm">// MultiMail inbound webhook payload received by Make's Webhooks module
{
"event": "email.inbound",
"mailbox_id": "[email protected]",
"email_id": "em_01HX3K9PQRST7VWYZ",
"thread_id": "th_01HX3K9ABCDEF1234",
"from": {
"address": "[email protected]",
"name": "Alex Rivera"
},
"subject": "Re: Invoice #4821",
"received_at": "2026-04-19T14:22:31Z",
"tags": ["billing", "urgent"],
"snippet": "Hi, I still haven't received the corrected invoice..."
}
// Register your Make webhook URL via MultiMail API:
// POST https://api.multimail.dev/v1/mailboxes/[email protected]/webhooks
// { "url": "https://hook.make.com/YOUR_WEBHOOK_ID", "events": ["email.inbound"] }Register a Make custom webhook URL with MultiMail. The payload shape below is what MultiMail POSTs to your scenario on every inbound message. Use the `tags` and `thread_id` fields to route to the correct branch in a Router module.
{
"url": "https://api.multimail.dev/v1/read_email",
"method": "POST",
"headers": [
{
"name": "Authorization",
"value": "Bearer $MULTIMAIL_API_KEY"
}
],
"body": {
"type": "raw",
"content": {
"email_id": "{{1.email_id}}"
}
}
}
"cm">// Response fields available for Make data mapping:
"cm">// result.email_id, result.subject, result.body_text,
"cm">// result.body_html, result.from.address, result.thread_id,
"cm">// result.tags[], result.attachments[]After a webhook trigger fires with an `email_id`, use a second HTTP module to fetch the full content before routing or processing it in downstream modules.
"cm">// Step 1: Queue message for approval (mailbox must be gated_send or gated_all)
"cm">// POST https://api.multimail.dev/v1/send_email
"cm">// Returns: { "status": "pending", "pending_id": "pnd_01HX9ZYXWVU87654" }
"cm">// Step 2: Set up a second Make scenario triggered by the approval webhook
"cm">// MultiMail POSTs to your webhook when the approver acts:
{
"event": "approval.completed",
"pending_id": "pnd_01HX9ZYXWVU87654",
"decision": "approved",
"email_id": "em_01HX9ABCDE12345",
"decided_by": "[email protected]",
"decided_at": "2026-04-19T15:04:11Z"
}
"cm">// Use a Router in your approval scenario to branch on decision == "approved"
"cm">// vs decision == "rejected" to notify the original requester accordingly.Call `decide_email` to create a pending message that requires approval. The API returns a `pending_id` immediately. MultiMail fires a separate `approval.requested` webhook when the approver acts, which can trigger a second Make scenario.
"cm">// Tag an email (called after read_email to classify it)
"cm">// POST https://api.multimail.dev/v1/tag_email
{
"email_id": "{{2.result.email_id}}",
"tags": ["escalated", "priority-high"]
}
"cm">// Search contacts linked to inbound senders
"cm">// POST https://api.multimail.dev/v1/search_contacts
{
"mailbox_id": "[email protected]",
"query": "{{1.from.address}}"
}
"cm">// Returns: { "contacts": [{ "id": "cnt_...", "email": "...", "name": "...", "tags": [] }] }
"cm">// Map result.contacts[].id into your CRM update module downstream.Tag inbound messages from Make for downstream routing, then search by tag to build aggregation scenarios. Both endpoints accept and return standard Make-mappable JSON.
Sign up at multimail.dev and create a mailbox — either a custom domain mailbox or one ending in `@multimail.dev`. Copy your `mm_live_...` API key from the dashboard. If you want approval gates, set the mailbox oversight mode to `gated_send` now.
In your Make scenario, add an HTTP > Make a request module. No official MultiMail connector exists yet, so all calls go through HTTP directly. Store your API key in Make's Connection vault or as a scenario variable — do not hardcode it in module configuration.
Create a new scenario starting with the Webhooks > Custom webhook module. Copy the generated Make webhook URL. Then POST to `https://api.multimail.dev/v1/mailboxes/{mailbox_id}/webhooks` with your Make URL and the events array `["email.inbound", "approval.completed"]`. MultiMail will now push events to your scenario.
curl -X POST https://api.multimail.dev/v1/mailboxes/[email protected]/webhooks \
-H "Authorization: Bearer $MULTIMAIL_API_KEY" \
-H "Content-Type: application/json" \
-d &"cm">#039;{
"url": "https://hook.make.com/YOUR_WEBHOOK_ID",
"events": ["email.inbound", "approval.completed", "approval.rejected"]
}&"cm">#039;Run your scenario once with a real email to let Make detect the webhook payload structure. Make will infer the field schema from the first real payload, making `email_id`, `thread_id`, `from.address`, `tags`, and `subject` available as mappable variables for all downstream modules including Routers, Filters, and data store writes.
Replace `mm_live_` with `mm_test_` keys during scenario development. Test-mode sends are recorded and inspectable in the dashboard but never delivered to real recipients. Switch to live keys only after the full scenario flow — including the approval branch — has been validated end to end.
Email infrastructure built for AI agents. Verifiable identity, graduated oversight, and a 38-tool MCP server. Formally verified in Lean 4.