Skip to main content
By the end of this page you will have:
  1. An identity with at least one warmed mailbox under it.
  2. An API key.
  3. A successful send to your own address.
  4. The email.sent event for that send, retrieved from the events stream.
1

Create an identity

Sign in at inboxbase.ai/app and create an identity. You pick a brand (the identity handle, e.g. alice.acme@inboxbase.ai) and a tier (which sets the daily send cap). Provisioning is asynchronous — it takes a few minutes the first time while we register domains and warm up the initial mailboxes.
The handle is what you’ll put in URLs. It’s not the address recipients see — they see whichever rotated mailbox we picked for that send.
2

Mint an API key

Go to Developers → API keys, click Create key, name it, copy the value somewhere safe. The key starts with sk_live_…. Keys are org-scoped: one key can act as any identity in your org. The identity is always identified in the URL path.
The key is shown once. Lose it and you mint a new one. There’s no “show again” button.
3

Send an email

Send a message to your own address so you can confirm delivery.
curl https://api.inboxbase.ai/v1/identities/alice.acme@inboxbase.ai/send \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "to":      "you@your-personal-domain.com",
    "subject": "Hello from 12m",
    "text":    "Reply to this and I will see it on the events stream."
  }'
You should see a 202 with a body that includes the convId of the new conversation, and the account field telling you which rotated mailbox we used.
4

Read the event

Every send writes an email.sent event to a per-identity log. You can pull from that log with a cursor — useful for development, agents, and any environment where you can’t expose a public webhook URL.
curl "https://api.inboxbase.ai/v1/identities/alice.acme@inboxbase.ai/events?since=0&limit=10" \
  -H "Authorization: Bearer sk_live_..."
The event you just produced will be in there with type: "email.sent", the convId from your send response, and a monotonic seq. That seq is the cursor for the next call.

​
What’s next

You have the loop. The rest of the docs explain how to use it well.

No-reply timers

The primitive that turns “send and wait” into “send and react.” Cheaper than running your own scheduler.

Reacting to replies

Push (webhooks) or pull (events stream) — same data, two delivery modes. Pick one or both.

Live thread list

The pattern for an inbox view that updates in real time without you maintaining a copy of our state.

Building a sequencer

Multi-step cold outbound on top of /send and the events stream. Your DB stays small.