| Hey HN, I built MailboxKit because I kept running into the same problem: AI agents need email but existing APIs aren't designed for them. The typical flow for an agent is: get an email address, send messages, receive replies, and handle threading — all via API, without a human setting things up. Most email services require manual domain verification, complex OAuth, or aren't built for programmatic access from the start. MailboxKit lets an agent self-register and start sending/receiving in a single API call: ```
POST /api/v1/register
{"name": "My Agent", "owner_email": "you@example.com"} → {"api_key": "mbk_...", "email": "abc123@agent.mailboxkit.com", "inbox_id": '19999d'}
``` That's it. The agent now has a real email address, can send and receive, and gets inbound messages via webhooks. Threading, read/unread tracking, attachments, and custom domains all work out of the box. The API docs double as an LLM-readable skill file (mailboxkit.com/skill.md) so agents using tool-use can discover and learn the API themselves. Currently used by a handful of agents doing customer support, research, and outreach. Would love feedback from anyone building agent infrastructure. |
Curious about deliverability on the shared domain — have you run into issues with @agent.mailboxkit.com landing in spam? In our experience, shared sending domains hit reputation problems fast once multiple tenants are sending from them, especially for outreach use cases.
The LLM-readable skill file idea is clever. We've been doing something similar with llms.txt for AI discoverability.
We also just shipped an OpenClaw plugin for Nylas (https://www.npmjs.com/package/@nylas/openclaw-nylas-plugin) that gives agents email, calendar, and contacts access out of the box — different approach since it connects to real user mailboxes rather than creating new addresses, but solves the same "agents need email" problem.