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:

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": "support",
    "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 is scanned for prompt injection before your agent reads it. Deliverability is managed per agent, and the platform's acceptable-use policy prohibits cold email outright — the shared infrastructure stays clean, which is what keeps support replies landing in the inbox.