Show HN: Email inbox for your OpenClaw agent (mailboxkit.com)
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.
1 comment
[ 3.3 ms ] story [ 21.3 ms ] threadCurious 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.