Skip to main content

We Run Our Own Support on Our Own API

· 5 min read
Yopie Suryadi
Founder, mailbot

A support ticket comes in. An AI agent reads it, classifies it, drafts a reply with full context, and sends it back. The entire loop runs on the same API we ship to developers.

This is not a demo. This is how we handle support at mailbot, every day, on our own infrastructure.

The Best Test Is the One You Can't Skip​

Dogfooding is not a new idea. Microsoft coined the term in the 1980s when a manager sent an internal memo titled "Eating our own Dogfood." Slack built its product by using it internally for months before anyone else could.

The pattern is clear: the products that hold up in production are the ones their own teams depend on. Not in a quarterly review. Not in a staged demo. In the moment when something breaks and you need the tool to work.

For mailbot, that moment is support. When a developer emails us with a problem, the clock starts. If our own infrastructure can't receive that email, classify it, and help us respond quickly, we have no business selling it to anyone else.

So we put our entire support workflow on our own API. Not as a marketing exercise. As an operational decision.

How It Works​

The flow is straightforward.

A customer sends an email to our support inbox. That inbox is a programmable mailbot inbox, the same kind any developer can create through our API. The message arrives, triggers an event notification, and gets picked up by our agent workflow.

The AI agent does three things:

  1. Classifies the ticket. Is this a bug report, a billing question, a feature request, or something else? The agent reads the full message body and assigns a category and priority.

  2. Drafts a reply. Using the classification and the original message as context, the agent generates a response. Not a template. A contextual reply that addresses what the customer actually wrote.

  3. Sends the reply through the mailbot API. The same messages.send endpoint our users call. Same SDK. Same authentication. Same event timeline tracking whether the reply was delivered, opened, or bounced.

import { MailbotClient } from '@yopiesuryadi/mailbot-sdk';

const client = new MailbotClient({ apiKey: 'mb_test_xxx' });

// Receive inbound via event notification handler
app.post('/webhooks/mailbot', async (req, res) => {
  const { type, data } = req.body;

  if (type === 'message.inbound') {
    const classification = await classifyTicket(data.text);
    const draft = await generateReply(data, classification);

    await client.messages.reply({
      inboxId: data.inboxId,
      messageId: data.id,
      bodyText: draft,
    });
  }

  res.sendStatus(200);
});

The thread stays intact because mailbot handles In-Reply-To and References headers automatically. The customer sees a normal email reply, threaded under their original message.

What We Learned​

Running support on our own API exposed things that testing alone never would.

Event notifications need to be fast and reliable. When a customer writes in, the event notification has to fire immediately. Early on, we found edge cases where retry timing wasn't optimal for real-time support workflows. We fixed them. Those fixes shipped to every mailbot user.

Thread continuity is harder than it looks. Customers forward emails, CC other people, and reply from different addresses. If your threading logic only handles the clean case, production will embarrass you. We tightened our threading engine because our own agent kept losing context in messy threads.

Per-message visibility is not optional. When a support reply bounces, we need to know within seconds, not the next day. Our event timeline, the same one available in the mailbot dashboard, became our primary debugging tool. If a message shows "delivered" but the customer says they didn't get it, we can trace the full delivery path.

AI classification is only as good as the data it gets. The agent receives the raw email, headers and all. Clean parsing matters. If the message body comes through garbled or if quoted text isn't properly separated, classification degrades. We improved our inbound parsing because we were eating our own output.

Why This Matters for Developers​

Every email infrastructure provider claims reliability. Fewer can show you that they depend on it themselves.

When we tell developers that mailbot handles two-way email conversations, thread continuity, and per-message observability, we're describing our own production workflow. Not a feature spec. Not a roadmap item. The system we wake up to every morning.

This is also why we catch issues fast. We're not waiting for a customer to report that event notifications are delayed or that threading broke on a forwarded message. We hit those problems first because we're running the same workflows our users run.

The best developer tools get built this way: used internally until they're genuinely useful to the team, then shipped externally. If you want to build infrastructure that works under pressure, put yourself under that pressure first.

The Full Loop​

mailbot is email infrastructure that gives AI agents the ability to email. We don't just say that. We run our own operations on it.

Every support ticket that comes in gets classified by AI, drafted with context, and sent back through the same API we ship to developers. One stack. Same endpoints. Same event timeline. Same deliverability.

If you're building an agent workflow that needs to send, receive, and act on email, start with the infrastructure that its own team trusts enough to run support on.

Start building at getmail.bot/docs/getting-started.