Durable Email Delivery for Trigger.dev Workflows

Connect Trigger.dev tasks to MultiMail's REST API for retry-safe email sends with oversight controls, approval gating, and full audit logging across every background job.


Trigger.dev handles the hard parts of background job orchestration — retries, scheduling, durable execution, and event-driven triggers. MultiMail handles the hard parts of email for AI agents — deliverability, oversight controls, and audit logging. Together they give you a complete pipeline for automated email workflows that remain under human control.

The integration is REST-based. Trigger.dev tasks call MultiMail's API directly using fetch, so there is no additional SDK to install. Any task that needs to send, read, or process email makes an authenticated HTTP request to https://api.multimail.dev.

Trigger.dev's retry semantics pair well with MultiMail's idempotent send API. A task that fails mid-run can safely retry the send_email call — passing a stable idempotency_key ensures recipients never receive duplicates even when a job re-executes.

For teams running agentic workflows, MultiMail's oversight modes let you gate automated sends through a human-approval queue without changing your task logic. A job running against a gated_send mailbox queues the email for approval rather than delivering immediately. Your task code stays the same; only the mailbox policy changes.

Built for Trigger.dev developers

Retry-safe delivery

Trigger.dev retries failed tasks automatically. MultiMail's send_email endpoint is idempotent when you supply a stable idempotency_key, so retried tasks never produce duplicate sends to recipients.

Human-approval gating without code changes

Switch a mailbox from autonomous to gated_send mode and every automated send from that task enters an approval queue. Your Trigger.dev task code is unchanged — the policy lives in the mailbox configuration, not in the job logic.

Audit log for every automated action

MultiMail logs every send, read, reply, and decide_email call with the API key, timestamp, mailbox, and outcome. For compliance with SOC 2 or GDPR audit requirements, background job email activity is fully traceable.

Inbound processing via scheduled tasks

Use Trigger.dev's cron schedules to poll check_inbox on a fixed interval, then read_email for each new message. This gives you a durable, retryable inbound-processing pipeline without managing a separate webhook listener.

Oversight modes that match your trust level

Start new agentic workflows in gated_all mode so every action requires human approval. Promote to monitored or autonomous as confidence grows. MultiMail's graduated oversight maps directly to Trigger.dev workflows at any maturity stage.


Try it with your agent

No code, no dashboard. Paste this to your AI agent — it connects MultiMail, creates an inbox, and builds the flow for you.

Implement a Trigger.dev agent integration with MultiMail. Use only real Trigger.dev AI agent primitives and only the MultiMail capabilities documented from its own setup material. 1. Get MultiMail ready: read https://multimail.dev/llms.txt first, connect the MultiMail MCP server exactly as documented there, create a free inbox for this agent, and set up a verified sending domain. Do not hardcode undocumented MultiMail routes, headers, providers, storage, or delivery details. 2. Wire MultiMail into the Trigger.dev agent using Trigger.dev’s chat.agent from @trigger.dev/sdk/ai and AI SDK tools. Declare the tools on the chat.agent config, receive the typed tools in run, pass them through chat.toStreamTextOptions({ tools }) into streamText, and keep Trigger.dev’s retries, runs, traces, and session history as the durable boundary for the workflow. 3. Add three agent capabilities as AI SDK tools backed by MultiMail: inbox-check to inspect the agent inbox, draft-reply to compose a reply without sending, and send to send or schedule email through the verified sender. Keep tool inputs explicit, validate them with schemas, and make every send request include enough caller-provided context to be retry-safe and auditable in the Trigger.dev run. 4. Send a test email: have the Trigger.dev agent check the new MultiMail inbox, draft a short reply, and attempt one test send to a developer-controlled address using the verified sender. Record the draft, recipient, subject, and final send decision in the Trigger.dev run logs or your app’s audit record. 5. Run the first version in MultiMail gated_send oversight mode. For any send or schedule action, pause for developer review before anything leaves the agent by using Trigger.dev’s human-in-the-loop pattern: model calls a no-execute approval tool, the UI collects approval with addToolOutput, and only the resumed turn calls the MultiMail send capability. Do not switch to monitored or autonomous until the gated_send test path is reviewed end to end.

Step by step

1

Create a MultiMail account and provision a mailbox

Sign up at multimail.dev, create a mailbox (e.g. jobs@acme.multimail.dev), and copy your API key from the dashboard. Set the mailbox oversight mode to gated_send during development so you can review sends before they reach recipients.

2

Add the API key as a Trigger.dev secret

Store your MultiMail API key as a secret in the Trigger.dev dashboard so it is available to all tasks at runtime without appearing in source code.

3

Create a task that calls send_email

Write a Trigger.dev task that calls the MultiMail send_email endpoint. Include an idempotency_key derived from your job ID so retries don't produce duplicate sends.

4

Deploy and test with a gated send

Deploy to Trigger.dev and trigger the task. Because the mailbox is in gated_send mode, the email will appear in your MultiMail approval queue rather than delivering immediately — verify the content before approving.

5

Switch to autonomous mode when ready

Once you've reviewed several sends and are confident in the output, change the mailbox oversight mode to monitored or autonomous from the MultiMail dashboard. No code changes are required — tasks continue calling send_email identically, but delivery now happens immediately.


Common questions

Do I need to install a MultiMail SDK to use it with Trigger.dev?
No. MultiMail is a REST API and works with any HTTP client. Trigger.dev tasks use the global fetch function available in Node.js 18+. Install nothing beyond the Trigger.dev SDK itself.
What happens if a task fails mid-run after calling send_email?
If you provide an idempotency_key in the send_email request, a retry will not produce a second delivery. MultiMail returns the original message ID on duplicate requests with the same key. Use a stable value derived from your Trigger.dev run ID or a hash of the payload.
Can I use Trigger.dev's scheduled tasks to poll for inbound email?
Yes. Use schedules.task with a cron expression to call check_inbox at a fixed interval, then read_email for each message ID returned. Because Trigger.dev retries failed runs automatically, a transient MultiMail API error won't leave messages unprocessed.
How does gated_send mode interact with long-running Trigger.dev tasks?
In gated_send mode, send_email queues the message rather than delivering it immediately and returns a message_id. Use wait.for to suspend the task for the expected approval window, then call list_pending to check whether the message was approved, cancelled, or is still awaiting review.
Does MultiMail handle email deliverability — SPF, DKIM, DMARC?
Yes. MultiMail manages SPF, DKIM, and DMARC alignment for all mailboxes. Custom domain mailboxes require DNS records provided in the dashboard; multimail.dev subdomains work without any DNS configuration.
Can I trace which Trigger.dev job sent which email for a compliance audit?
Yes. Embed a job identifier in the idempotency_key or a metadata field on each send_email call. MultiMail logs every API call with the key, mailbox, timestamp, and outcome. For SOC 2 or GDPR audit trails you can correlate Trigger.dev run IDs with MultiMail message IDs.
What oversight mode should I start with for a new agentic workflow?
Start with gated_send: reads are autonomous but sends require human approval. This lets you review what the agent sends before committing to autonomous delivery. Promote to monitored after validating output over several runs, then to autonomous when confidence is established.

Explore more

The only agent email with a verifiable sender

Email infrastructure built for AI agents. Verifiable identity, graduated oversight, and a hosted MCP server. Formally verified in Lean 4.