Email API for AI ecommerce agents

The problem

Ecommerce email is two jobs that every tool treats as one.

The first is outbound and high volume: order confirmation, shipping notice, delivery confirmation, return label, review request. Any sending API does this.

The second is what happens next. The customer hits reply. "This is the wrong size." "It says delivered and it isn't here." "Can I change the address?" That reply goes to whatever address you sent from, and for most shops that is noreply@, where it dies. The customer then emails support separately, with no order number, and your agent starts from nothing.

The fix is not a better send API. It is sending from an address that can receive.

One thread, both directions

Send the order confirmation from a real inbox, and the reply lands on the same thread as the confirmation. The agent calling get_thread sees the order number, the items and the shipping address without asking, because they are in the message above.

That one change removes most of the work people build agents to do: no order lookup from a free-text email, no "can you tell me your order number", no separate support queue that has lost the context.

Anjal writes Message-ID, In-Reply-To and References on everything it sends and tracks them on everything it receives, so replies thread properly in Gmail, Outlook and Apple Mail rather than arriving as unrelated messages.

Volume without wrecking your domain

Transactional ecommerce mail is bursty and repetitive, which is exactly the shape that gets a sending domain into trouble.

• Per-inbox bounce and complaint limits pause a single inbox automatically rather than letting a bad address list take your whole domain down with it. Measured over a rolling 7-day window, so old, unrelated failures age out instead of accumulating into a permanent stop.
• A new-account ramp starts you at a low daily volume and lifts it as the account ages. This is deliberate and it will apply to you on day one: a brand new paid account is capped at 20 sends in its first 24 hours, 50 a day for the first week, 500 a day to 30 days. Plan the migration around it rather than discovering it on Black Friday.
• Identical-content detection notices when you are sending the same template to everyone. It does not block the send; it tells us, so nobody's password resets or dispatch notices get refused.
• MX validation on every recipient rejects typo domains before they become bounces.

Separate inboxes for separate jobs

Create one per function rather than one per shop: orders@, returns@, support@. Each gets its own reputation, its own bounce accounting and its own pause, so a bad returns list cannot stop order confirmations going out.

If you run several storefronts, put each in its own workspace. A workspace-scoped key reaches that workspace's inboxes and nothing else, so one brand's agent can never read another brand's mail. You get one workspace per inbox on your plan, so three brands with three inboxes each fits inside Developer.

What it looks like

# send the confirmation from an inbox that can receive
curl -X POST https://anjal.app/v1/inboxes/$ORDERS_INBOX/send \
  -H "X-API-Key: $ANJAL_KEY" -H "Content-Type: application/json" \
  -d '{"to":"customer@example.com",
       "subject":"Order 10482 confirmed",
       "plainBody":"Thanks! Your order is on the way.",
       "labels":["order-confirmation"]}'

The customer replies. A message.received webhook fires, the agent calls get_thread, reads the confirmation it sent, and answers with the order already in context. For anything touching a refund or an address change, use create_draft and let a person send it.

Fit

Good fit if customers reply to your transactional mail and you want an agent to handle those replies with the order in context, or you run multiple storefronts that must stay isolated.

Not a fit if you only need bulk outbound and nothing reads the replies. A pure sending API will be cheaper; see Anjal vs Amazon SES.

Also not a fit for marketing campaign blasts. The limits above are built for transactional and agent-driven mail, not for a newsletter to 200,000 people.

Cost

Starter is $5/month for 2 inboxes and 6,000 emails. Developer is $15/month for 10 inboxes and 20,000 emails. Startup is $199/month for 200 inboxes and 150,000 emails. Extra email is $2/month per 1,000, so size on your monthly send volume plus the replies.

Related

• AI customer support agents
• Transactional email
• Multi-tenant SaaS for the workspace-per-brand pattern
• Email deliverability for agents