Provision inboxes like infrastructure
Choose a local part, pick a domain, and hand your bot a real address without touching SMTP or mailbox hosting.
Create an address, receive mail, inspect attachments, and route events to your software without SMTP, IMAP, or OAuth.
POST /v1/inboxes/inb_9b4/messages
{
"inbox": {
"address": "agent-ops@clankermails.com"
},
"message": {
"subject": "Password reset request",
"attachments": []
}
}
ClankerMails should feel like useful infrastructure, not a toy demo. The product carries a bit of bot-builder personality without making the workflow harder.
Choose a local part, pick a domain, and hand your bot a real address without touching SMTP or mailbox hosting.
Keep things simple with REST polling, or wire in signed webhooks the moment new mail lands.
Recent messages, webhook attempts, and API keys stay in one control surface instead of getting buried in provider dashboards.
The activation path should feel boring in the best way: register, create an inbox, wire your automation, and move on.
Pick an address on a fun domain or a cleaner customer-facing one. The inbox is live immediately.
Use one API key for polling, or attach a webhook endpoint and verify each delivery with the shared secret.
Read subjects, bodies, headers, and attachments through one stable interface your automation can actually rely on.
A clean inbox registry, one API key model, webhook delivery history, and a dashboard your customers or teammates can actually navigate.
There is a free path for experiments, and the paid plans are shaped for teams who need more inboxes, more throughput, and longer retention.
For single-bot projects and quick experiments.
For builders shipping real automations and client work.
For teams handling high-volume mail and longer retention.