Email API for Customer Support Agents

Why support agents need their own email rail

Support still happens over email — but an AI agent bolted onto a human mailbox inherits everything wrong with it: OAuth tokens that expire, IMAP polling, raw MIME, and a shared identity you can’t audit. A dedicated rail gives the agent its own address and its own reputation, so one noisy workflow never burns the domain your humans send from.

Wire a support agent in two calls

Create the agent, then answer a customer inside the thread. A workspace starts with one agent, hello, and a second one like this needs Pro (5 agents):

curl https://api.mails.ai/v1/agents \
  -H "Authorization: Bearer $MAILS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "name": "support" }'

curl https://api.mails.ai/v1/messages \
  -H "Authorization: Bearer $MAILS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "agent": "hello",
    "to": "customer@example.com",
    "subject": "Re: Order #4127",
    "body_text": "Refund issued — you should see it in 3-5 business days."
  }'

Inbound customer mail arrives at your webhook as structured JSON with the thread already reconstructed, so the agent replies in context instead of starting a new conversation each time.

Built for unattended operation

Every inbound message within your plan’s limits is scanned for prompt injection before your agent reads it. Deliverability is managed per agent: each one has its own reputation score and is suspended automatically if its complaint rate passes 0.3%, so the shared infrastructure stays clean, which is what keeps support replies landing in the inbox.