Sendmux

Email for AI scheduling agents

A booking is a conversation: a request, a few proposed times, a confirmation, a reminder. Your agent has to receive and reply, not just send.

Sendmux gives the agent a real mailbox. It catches the request, reads the times clean, keeps the whole lifecycle in one thread, and won’t get suspended mid-booking.

Free @myagent.mx mailboxNo credit cardNo DNS setup
scheduling@myagent.mx · thread live
jordan@example.com · nowCan we find 30 min next week? Thursday afternoon works.
agent · proposesHow about Thursday 10am or Friday 11am your time?
jordan@example.comThursday 10am is perfect.
agent · confirmsConfirmed for Thursday 10am.invite.ics
agent · remindsReminder: our call is tomorrow at 10am.
lifecycleawaiting_replytimes_proposedconfirmedreminded

<TL;DR for AI agents>

What your scheduling agent runs, in three calls.

What the agent gets

  • Give one agent a scoped mailbox. It reads the request, proposes times, confirms, and reminds, over REST or MCP.
  • A live event wakes the agent the moment a request lands. No polling, so a booking never waits on a timer.
  • Read the proposed times clean, with the booking link pulled out and the timezone kept intact.

One scoped credential covers the whole lifecycle: read, propose, confirm, and remind.

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

# Read the times clean, booking link pulled out
$ curl "https://app.sendmux.ai/api/v1/mailbox/messages/msg_123/content
?strip_quotes=true&include_links=true" \
  -H "Authorization: Bearer smx_mbx_your_key"

Booking lifecycle

One thread, the whole lifecycle.

A booking moves through states: awaiting a reply, times proposed, confirmed, reminded. The label is the state, and your agent reads it back at every step.

A live event wakes your agent when a request lands. It reads the proposed times clean, checks its own calendar, and replies with slots that work. The thread is labelled times_proposed.

When the invitee picks a time, the agent confirms from the same address and attaches an .ics it built. The label flips to confirmed, so the state is never in doubt.

The agent’s own timer nudges before the meeting. If plans change, it catches the reschedule email, offers new slots, and relabels the thread. The lifecycle loops without losing the history.

reschedule loops the thread back

Structured parsing

Read the times, not the noise.

Booking emails arrive with quoted history, a signature, and the good part buried in the middle. Sendmux returns clean JSON with the times intact and the booking link pulled out, so your agent reads the request and spends fewer tokens.

Raw email · booking request

From: jordan@example.comSubject: Can we find 30 min next week? Thursday afternoon works, or Friday before noon. 10am your time is ideal.Or just grab a slot: cal.example.com/jordan On Mon 6 Jul, scheduling-bot wrote:> Happy to set something up. When suits you? -- Sent from my iPhoneJordan, Head of Ops
4lines the agent reads−5
GET /messages/msg_123/content
{
  "text": "Thursday afternoon works, or Friday before noon. 10am your time is ideal.",
  "quotes_stripped": true,
  "signature_stripped": true,
  "extracted_links": ["cal.example.com/jordan"]
}
  • Strips quoted history and signatures, so the model reads the request, not the thread.
  • Pulls booking links into a typed array, ready for your agent to open or ignore.
  • Keeps natural-language times intact, like “Thursday afternoon” and “10am your time”, for the model to resolve.
  • Returns the full thread on demand, so a timezone agreed three emails back is still there.

Multi-party

Coordinate a room, not just a reply.

A meeting with three people is three inboxes and three replies. Your agent emails each attendee from one mailbox, catches every response in the same thread, and reads them clean, so it can find the slot that works for the room and send one invite. A send-only API can receive none of this.

Replies, threaded back

alex@example.comWed or Thu both fine
sam@example.comnot Wed, Thursday is good
priya@example.comeither day works for me
WedThualexsampriya
Overlap: Thursday 10am. One invite goes to all three.
POST /mailbox/messages/send
# One send, three attendees. Replies thread back.
$ curl -X POST https://app.sendmux.ai/api/v1/mailbox/messages/send \
  -d '{ "to": [
      { "email": "alex@example.com" },
      { "email": "sam@example.com" },
      { "email": "priya@example.com" } ],
    "subject": "Finding 30 min next week" }'
✓ 200 sent to 3 · replies grouped by thread

Confirm, remind, reschedule

One mailbox: confirm, remind, adapt.

Send the confirmation with an invite, nudge before the meeting on your agent’s own clock, and when plans change, offer new slots and relabel. All from the same mailbox, all in one thread.

threadRe: Can we find 30 min next week?+ confirmedawaiting_reply: falsereminded
POST /messages/send · batch-update 200
# 1. Confirm the slot, attach the .ics invite
$ curl -X POST https://app.sendmux.ai/api/v1/mailbox/messages/send \
  -d '{ "to": [{ "email": "jordan@example.com" }],
        "text_body": "Friday 10am your time works, invite attached." }'
✓ 200 sent · labelled confirmed

# 2. Your agent’s timer nudges the day before
$ curl -X POST https://app.sendmux.ai/api/v1/mailbox/messages/send \
  -d '{ "text_body": "Reminder: our call is tomorrow at 10am." }'
✓ 200 sent in thread
# 3. Plans change: relabel, offer new slots
$ curl -X POST https://app.sendmux.ai/api/v1/mailbox/messages:batch-update \
  -d '{ "keywords": { "reschedule": true, "confirmed": false } }'
✓ 200 lifecycle updated

The reminder fires on your agent’s own clock. Sendmux has no scheduled send; the agent decides when to hit send.

1,800

sends per minute

100

messages per thread read

50

labels per update

$0.15

per 1,000 inbound

lifecycleawaiting_replytimes_proposedconfirmedreminded

Control the inbox

Filter the noise, scope the key.

A public booking address attracts spam and cost. Sender rules keep it out, and a mailbox-scoped key keeps the agent boxed to its own inbox.

Scoped key

A key boxed to one mailbox

The agent uses a mailbox credential that only reaches its own inbox. Team-wide keys are rejected here, so it can never read another booking mailbox. Or connect over MCP and skip static keys.

GET /mailbox/me
# One credential, one mailbox. Team keys are rejected here.
$ curl https://app.sendmux.ai/api/v1/mailbox/me \
  -H "Authorization: Bearer smx_mbx_scheduling_agent_key"

Sender rules

Keep spam out of the inbox

Set the mailbox to allow or deny by sender. Rejected mail never reaches the agent, and it is not billed, so a public booking address stays cheap and quiet.

attendee@…spam@…
  • Allowlist or denylist senders by address or pattern.
  • Spam lands on its own event, kept out of the booking flow.
  • Mail rejected by a rule is free, no charge for noise.
  • Rules read back in order, so the agent sees a stable queue.

1,800/min

sends per mailbox

100per thread

messages read

50per call

labels set

$0.15/1k

inbound email

Common questions

What scheduling teams ask first.

No. Sendmux is the email layer under your scheduling agent, not a scheduling product. Your agent, with its own calendar, decides the time. Sendmux gives it the mailbox, the clean content, the thread, and the send, so it can run the booking over email.

It sends when your agent decides, the moment the agent decides. There is no delayed send, so a reminder fires on your agent’s own clock. Your agent can attach an .ics it built, and Sendmux delivers it, but it does not generate or read the file.

Yes. Send from one mailbox to every attendee, and each reply threads back to the same conversation. Your agent reads them clean, finds the slot that works for everyone, and sends one invite. A send-only API cannot receive the replies at all.

Sendmux returns the natural-language text and the full thread clean, so your agent’s model reads “10am your time” or “Thursday afternoon” exactly as written. Sendmux does not parse or convert times; the model resolves them.

Yes. A reschedule email threads back to the same conversation, so your agent offers new slots, updates the labels, and sends a fresh invite. Nothing is locked server-side, and the whole history stays in one thread.

Yes. Run the mailbox on your own verified domain with guided DNS, or start instantly on a shared @myagent.mx address. For outbound, route through your own providers or the managed Amazon SES account.

Email for AI scheduling agents

From first request to final reminder, one mailbox.

Catch the request, propose times, confirm the slot, and nudge before the meeting. Every state lives in one thread, usage-based, and nothing gets suspended mid-booking.

Free @myagent.mx mailboxNo card requiredUsage-based pricing