Sendmux

AI agent monitoring that starts in the inbox

Sendmux is the email API for AI monitoring agents. Give your agent a real mailbox that catches every inbound alert, de-dupes the firehose, and escalates the ones that matter.

Alerts pour in from every tool you run. Your agent tells signal from noise and pages only what counts. One API for the events, the parsing, and the outbound page.

Free @myagent.mx mailboxNo credit cardNo DNS setup
watch@myagent.mx live
[P1] api.yourdomain.dev returning 5xx (12% error rate)statuscheck.example.compage
New issue: TypeError in checkout-worker (240 events/hr)error-tracker.example.netdigest
[P1] api.yourdomain.dev returning 5xx (12% error rate)statuscheck.example.comdropped
Build failed: nightly-export exited 1 on shard 3builds.example.netdigest
Anomalous sign-in: 40 failed attempts from 3 networksscanner.example.comdigest
noise  →  signal12 caught1 paged

<TL;DR for AI agents>

What your monitoring agent runs, in two calls.

What the agent gets

  • Give one agent a scoped mailbox. It catches every inbound alert over a signed webhook or a live event stream.
  • Duplicate alerts are absorbed for 24 hours, so a retry storm never pages your on-call twice.
  • Read each alert clean, quotes and signatures stripped, so the model reads the signal, not the padding.

One scoped credential covers the loop: catch the alert, read it clean, and escalate.

GET /mailbox/events 200
# Wake the moment an alert lands
$ curl -N "https://app.sendmux.ai/api/v1/mailbox/events?event_types=message.received" \
  -H "Authorization: Bearer smx_mbx_your_key"

# Read it clean, runbook link pulled out
$ curl "https://app.sendmux.ai/api/v1/mailbox/messages/msg_8842/content
?strip_quotes=true&strip_signature=true" \
  -H "Authorization: Bearer smx_mbx_your_key"

The triage loop

From firehose to one clear signal.

Alerts land from every tool you run. Your agent keeps the one that pages someone and files the rest.

12

alerts land

Uptime, errors, security, and CI, all to one mailbox.

2

blocked by the allowlist

Mail from senders you didn’t name is rejected before it’s billed.

3

absorbed as duplicates

Repeats of the same event are dropped for 24 hours.

7

read clean, then classified

Your agent scores each alert on a token-light body.

1 · 6

paged, then digested

One escalation send fires, and it can’t fire twice.

Your agent’s own model does the scoring. Sendmux moves, filters, and cleans the mail.

Two ways in

Push a webhook, or hold the stream open.

Both carry the same message.received event. Pick the shape your agent runs best.

Signed webhook

Sendmux POSTs each message.received to your HTTPS endpoint, signed with HMAC-SHA256 so you can trust the source before you act on it.

verify signature
# each POST carries a signature header
X-Sendmux-Signature: sha256=<hmac>

# recompute over the raw body, compare
verify: hmac_sha256(rawBody, secret)

Event stream

Or hold one connection open and read alerts as Server-Sent Events. Reconnect with Last-Event-ID and no alert slips through the gap.

hold connection open connected
# one long-lived request, events push in
$ curl -N .../v1/mailbox/events
  ?event_types=message.received
watch@myagent.mx · sender rulesallowlist
allowstatuscheck.example.comuptime
allowerror-tracker.example.neterrors
allowscanner.example.comsecurity
allowbuilds.example.netci
denypromo@newsletter.example.ionot billed

Sender rules

Let the alerts in, keep the noise out.

  • A public alert address invites spam. An allowlist accepts only the senders you name and rejects the rest.
  • Rules run before a message is accepted, so blocked mail is rejected upstream and never billed.
  • Set up to 1,000 rules per mailbox, or apply them across the whole domain.

De-dupe

One incident, one page.

Without de-dupe0× paged

A retry storm delivers the same alert five times. Your on-call agent pages the human five times at 3am.

attempt 1 · paged
attempt 2 · paged
attempt 3 · paged
attempt 4 · paged
attempt 5 · paged

With Sendmux0× paged

Repeats of the same event are absorbed for 24 hours, and an Idempotency-Key on the escalation send means the page fires once, even when your agent retries.

attempt 1 · delivered
attempt 2 · same event id, absorbed
attempt 3 · same event id, absorbed
attempt 4 · same event id, absorbed
attempt 5 · same event id, absorbed

Clean content

Parse the alert, not the padding.

Machine alerts carry headers, footers, and boilerplate your agent doesn’t need. Ask for clean content and get the signal, with the noise stripped out.

  • Strips signatures and boilerplate, so the model reads the incident, not the footer.
  • Pulls the runbook link into a typed array, ready for your agent to open.
  • Caps the body at 100,000 characters, so a noisy alert can’t blow your token budget.
  • Returns attachment metadata, like filename and size. Your agent fetches the report itself.
From: alerts@statuscheck.example.com
Subject: [P1] api.yourdomain.dev returning 5xx
 
Error rate 12% over 5 min. Region: ap-southeast.
Runbook: status.example.com/incidents/8842
 
Do not reply. Manage alerts in your dashboard.
Unsubscribe · Preferences · View in browser
StatusCheck Pty Ltd, 12 Signal St

Grey lines are stripped. Your agent reads the incident and the runbook link, nothing else.

Escalate

Send the page, file the rest.

When an alert clears the bar, your agent pages with a normal send. An Idempotency-Key means a retried escalation fires once, not five times.

POST /emails/send 200
# Escalate: page on-call, once
$ curl -X POST https://smtp.sendmux.ai/api/v1/emails/send \
  -H "Authorization: Bearer smx_mbx_your_key" \
  -H "Idempotency-Key: incident-8842" \
  -H "Content-Type: application/json" \
  -d { "from": { "email": "watch@yourdomain.dev" },
     "to": { "email": "oncall@yourdomain.dev" },
     "subject": "[P1] api 5xx, paged",
     "text_body": "Error rate 12%. Runbook attached." }
200 · paged onceretry · same Idempotency-Key → not sent again

24h

idempotency window

100

sends per batch

1

thread per incident

8attempts

every webhook retried

24hours

duplicate events absorbed

1,800/min

requests per mailbox key

100kchars

clean-body cap per alert

Common questions

What monitoring teams ask first.

No. Sendmux is the email layer under your AI agent monitoring. It catches the inbound alert, de-dupes it, and hands your agent clean content. Your agent’s own model decides what’s a P1 and who to page. There’s no rules engine or paging schedule built in.

Two ways. Point a signed webhook at the message.received event and Sendmux POSTs it to your endpoint, or open the event stream and read alerts as Server-Sent Events. Both use the same event names, so you pick the shape that fits your runtime.

Duplicate events are absorbed for 24 hours, so a retry storm upstream doesn’t reach your agent twice. On the way out, an Idempotency-Key on the escalation send means a retried page fires once, not five times.

Yes. Set an allowlist of the senders you trust, and mail from anyone else is rejected before it’s accepted. Blocked mail is rejected upstream, so you’re not billed for it. Rules apply per mailbox or across the whole domain.

Not the contents. The clean-content endpoints return the message body plus attachment metadata, like filename and size. They don’t parse the inside of a PDF, CSV, or spreadsheet. Your agent fetches and parses attachments itself.

Sendmux retries each webhook 8 times across a 24-hour window. If every attempt fails, it marks the webhook failing and emails the team owner, and delivery records are kept for 7 days so you can see what happened.

Email for AI monitoring agents

Catch every alert, page only what matters.

Give your monitoring agent a real mailbox that de-dupes the firehose, reads each alert clean, and escalates the ones that matter. One inbound email API, usage-based.

Free @myagent.mx mailboxNo card requiredUsage-based pricing