Skip to main content

Quickstart: Send Your First Email with mailbot in 3 Minutes

· 5 min read
Yopie Suryadi
Founder, mailbot

Three API calls. One real email. No DNS setup required.

Most email APIs promise you can "get started in minutes." Then you click "Get Started" and the real journey begins.

Verify your domain. Add three DNS records. Wait for propagation. Configure SMTP credentials. Pick a sending IP. Set up SPF. Set up DKIM. Pray that DMARC doesn't break everything.

By the time you send your first email, your coffee is cold and your motivation is somewhere else entirely.

Let's try something different.

What you need​

One thing: an API key. That's it.

Go to the mailbot dashboard and grab your key. No credit card. No approval queue. No "request access" form that sends you to a waitlist. You get a key that looks like this:

mb_live_xxxxxxxxxxxx

You're ready.

Step 1: Create an inbox​

Every email needs a sender. In mailbot, that means an inbox. One API call creates one.

curl -X POST https://getmail.bot/v1/inboxes \
  -H "Authorization: Bearer mb_live_xxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "username": "hello",
    "display_name": "Hello Bot",
    "domain": "mailbot.id"
  }'

Response:

{
  "data": {
    "id": "inbox_01hrz7nq9mvy7a6d2x2g8n3m4b",
    "address": "hello--abc123@mailbot.id",
    "username": "hello",
    "display_name": "Hello Bot",
    "domain": "mailbot.id",
    "status": "active",
    "permissions": ["send", "receive", "search"],
    "daily_send_limit": 250,
    "sends_today": 0,
    "created_at": "2026-03-13T10:00:00.000Z"
  }
}

That's it. You now have a working shared-path inbox: hello--abc123@mailbot.id. Not a fake mock. Not a throwaway alias. A real inbox you can use to send, receive, and inspect email behavior fast.

For the shared sandbox, use the returned inbox address as your canonical inbox email. The pattern is {inbox}--{account_short_id}@mailbot.id.

No DNS changes. No domain verification. No support ticket. One API call.

Step 2: Send an email​

Now send something. Use the inbox ID from the previous response.

curl -X POST https://getmail.bot/v1/inboxes/inbox_01hrz7nq9mvy7a6d2x2g8n3m4b/messages \
  -H "Authorization: Bearer mb_live_xxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "to": ["your-email@example.com"],
    "subject": "Hello from mailbot",
    "body_text": "This is your first email sent through mailbot. It took two API calls to get here."
  }'

Response:

{
  "data": {
    "id": "msg_01hrz8mym5g0py2xaxv6psgt9p",
    "thread_id": "thr_01hrz8b47p66w8b6wk0f55c2xk",
    "compliance_status": "passed",
    "created_at": "2026-03-13T10:01:00.000Z"
  }
}

Go check your inbox. The email is there.

What just happened​

Two API calls. That's what happened. Let me point out a few things you might have missed.

The email went through real infrastructure. Not a sandbox. Not a simulation. mailbot sends through its own proprietary MTA with industry-leading deliverability. Your email landed in the inbox because it was sent from infrastructure with a proven track record behind it.

You got a thread ID back. That thread_id in the response is not decoration. When someone replies to this email, mailbot will automatically associate the reply with this thread. You don't need to parse headers. You don't need to manage Message-ID references manually. The threading is handled server-side.

Compliance was checked before sending. See compliance_status: passed? mailbot runs compliance checks on every outbound message before it leaves the system. If something would hurt your deliverability or violate email standards, you'll know before the email goes out, not after.

The inbox can also receive. Notice the permissions: ["send", "receive", "search"] in the inbox response? That inbox is not send-only. When someone replies to your email, the reply lands in mailbot. You can retrieve it, search it, and build workflows on top of it. Two-way email from the start.

What to do next​

You have a working inbox and a sent email. Here are three directions you can go from here.

Check engagement​

Want to know if your email was delivered? Opened? Clicked?

curl https://getmail.bot/v1/engagement/events?inbox_id=inbox_01hrz7nq9mvy7a6d2x2g8n3m4b \
  -H "Authorization: Bearer mb_live_xxxxxxxxxxxx"

This returns every engagement event for that inbox: delivered, opened, clicked, bounced. Per message. Not aggregated into a campaign report you can't act on. Per message.

Set up event notifications​

If you want to know when someone replies (or when any event happens), register an event notification endpoint:

curl -X POST https://getmail.bot/v1/webhooks \
  -H "Authorization: Bearer mb_live_xxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://your-app.example.com/webhooks/mailbot",
    "events": ["message.received", "message.sent"]
  }'

Now every inbound email and outbound confirmation gets POSTed to your endpoint in real time.

Reply in thread​

When you receive a reply, you can respond in the same thread:

curl -X POST https://getmail.bot/v1/inboxes/inbox_01hrz7nq9mvy7a6d2x2g8n3m4b/messages/{msgId}/reply \
  -H "Authorization: Bearer mb_live_xxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "body_text": "Thanks for your reply. Let me look into this."
  }'

mailbot handles the threading headers automatically. The conversation stays intact in the recipient's email client.

That's the whole quickstart​

No 47-step onboarding guide. No "now configure your DNS and wait 48 hours." No "contact sales for production access."

You created an inbox. You sent an email. The infrastructure is real, the email is real, and the thread is already being tracked. Everything that follows, engagement tracking, event notifications, reply handling, builds on these same two API calls.

Go build something.

mailbot is programmable email infrastructure. Read the docs · Get API key