Retool as Your AI Email Approval Dashboard

Wire MultiMail's pending queue into a Retool app and give your operations team a clean interface to review, approve, or reject AI-drafted email before it sends.


Retool is where operations teams build the internal tools that run their business — dashboards, approval queues, and workflow forms layered on top of APIs and databases. When you add AI agents to that picture, Retool becomes the natural surface for humans to stay in the loop.

MultiMail's graduated oversight modes let AI agents draft and queue outbound email without sending autonomously. The `gated_send` and `gated_all` modes hold email in a pending queue until a human approves. Retool can query that queue, surface full email content and agent metadata, and let reviewers approve or reject with a single click.

The integration requires no custom backend. Retool queries MultiMail's REST API directly. A resource pointing to `https://api.multimail.dev` with your Bearer token is all the infrastructure you need — no proxy, no Lambda, no middleware.

Built for Retool developers

Pending queue is REST-native

MultiMail's `GET /v1/oversight/pending` endpoint returns structured JSON — an emails array with id, subject, from, to, body_markdown, and status — that maps directly to Retool table columns with no transformation layer.

Approve or reject in a single API call

The `POST /v1/oversight/decide` endpoint takes an `email_id` and an `action` of `approve` or `reject`. Wire it to a Retool button and the queue drains without any custom middleware.

Webhook-driven reviewer notifications

MultiMail fires webhooks when new emails enter the pending queue. A Retool Workflow can receive those events and post to Slack or trigger in-app notifications so reviewers don't have to poll.

Audit trail built in

Every approve and reject is logged with a timestamp. MultiMail surfaces this through the audit log (`GET /v1/audit-log`), giving you a complete chain of custody suitable for SOC 2 and GDPR data processing reviews.

Per-mailbox oversight mode

Different mailboxes can run different oversight modes. High-stakes outbound — sales, legal, external partners — stays in `gated_send`. Internal notifications can run `monitored` or `autonomous`. Retool surfaces only what needs human review.


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.

1. Get MultiMail ready: read https://multimail.dev/llms.txt, connect the MultiMail MCP server to this agent, create a free inbox for this workflow, and set up a verified sending domain so replies can be sent from an approved sender. 2. Wire this into Retool using Retool Workflows or Retool Agents with Retool resources and functions/tools: create a Retool resource or callable function that lets the Retool agent invoke the connected MultiMail MCP tools, then build a Retool app page for the operations team with a table of pending AI-drafted messages and detail controls for review. 3. Give the agent exactly these capabilities through the connected MultiMail MCP tools: check the inbox for new messages, draft replies for selected conversations, and send or schedule approved email. Do not send anything automatically while testing. 4. Send a test email into the new MultiMail inbox, have the Retool agent check the inbox, generate a draft reply, and show the draft in the Retool review interface with enough context for an operator to approve or reject it. 5. Run MultiMail in gated_send oversight mode: every AI-drafted message must stay pending until a human reviewer in Retool approves it, and rejected drafts must not send. After approval, use the MultiMail send capability from the verified sender only.

Step by step

1

Create a MultiMail REST API resource in Retool

In Retool, go to Resources → Create New → REST API. Set Base URL to `https://api.multimail.dev` and add a default header: `Authorization: Bearer {{ retoolContext.environmentVariables.MULTIMAIL_API_KEY }}`. Store your `mm_live_...` key as a Retool environment variable so it is encrypted at rest and not exposed to app end users.

2

Create your outbound mailbox in gated_send mode

Provision the mailbox with oversight set to hold outbound email for review rather than delivering immediately. Agents writing to this mailbox will have their messages queued until a Retool reviewer approves. (Set oversight_mode at creation, or change it later in the MultiMail dashboard.)

3

Build the pending queue table

Create a Retool app with a Table component. Add a REST API query to your MultiMail resource: GET `/v1/oversight/pending`. Set the table's data source to `{{ getPendingEmails.data.emails }}` and add columns for id, from, to, subject, status, and received_at.

4

Wire Approve and Reject buttons

Add two buttons below the table. For Approve, create a JavaScript query that calls `POST /v1/oversight/decide` with `{ email_id: table1.selectedRow.data.id, action: 'approve' }`. For Reject, send `{ email_id: table1.selectedRow.data.id, action: 'reject' }`. On success, trigger `getPendingEmails` to refresh the queue.

5

Add a Retool Workflow for queue alerts

Create a Retool Workflow on a cron schedule (e.g. every 5 minutes) that polls `GET /v1/oversight/pending` and counts the emails awaiting approval. When the count crosses a threshold, notify your team via Slack or email before they open the review app. (For inbound delivery, subscribe a webhook to `email.received` instead.)


Common questions

Does this integration require a backend server or middleware?
No. Retool queries MultiMail's REST API directly from its built-in query runner. A REST API resource configured with your Bearer token is sufficient. Retool Workflows handle webhook ingestion without any custom server.
How do I prevent my API key from being visible to Retool app users?
Store your `mm_live_...` key as a Retool environment variable and reference it as `{{ retoolContext.environmentVariables.MULTIMAIL_API_KEY }}` in query headers. Retool encrypts environment variables at rest and does not expose them to end users of your published apps.
What happens if two reviewers try to approve the same email simultaneously?
The first `POST /v1/oversight/decide` call wins; once an email is approved or rejected it leaves the pending queue, so a second decide on the same email ID no longer finds it pending. Design your Retool app to refresh the table after each decision so reviewers see current queue state and don't act on already-decided emails.
Can I display the full formatted email body, including HTML, in Retool?
Yes. Call GET `/v1/mailboxes/{mailbox_id}/emails/{email_id}` when a reviewer selects a row to fetch the full email. The response includes the message body as `body_markdown`. Render it inside a side drawer — convert the markdown to HTML in a Retool transformer if you want formatted output.
How do I record which Retool user approved each email for compliance?
Every `POST /v1/oversight/decide` call is recorded in MultiMail's audit log, retrievable via GET `/v1/audit-log` — the decision, the email ID, and the timestamp. The audit log is the chain of custody suitable for SOC 2 audits and GDPR data processing records. To attribute a decision to a specific Retool user, also record `current_user.email` in your own app's logging when the button is clicked.
Can emails in the pending queue expire automatically if not reviewed?
A pending email stays in the queue until it is explicitly approved or rejected — there is no built-in auto-expiry. To enforce a review deadline yourself, run a Retool Workflow on a schedule that lists `GET /v1/oversight/pending`, checks each email's `received_at`, and cancels anything past your cutoff with `POST /v1/mailboxes/{mailbox_id}/emails/{email_id}/cancel`.

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.