Your AI agent's personal email

Give your AI agent its own personal email address.
Send, receive, search, reply, and forward — right from Claude, Gemini, Codex, or any MCP-compatible client.

One command. No server to run. No SMTP to configure. Completely free.

Get Started → Docs

Not a wrapper around SES or SendGrid. We built the entire email stack from the ground up — from receiving mail to delivering it to the inbox.

Why InboxAPI

Everything your AI agent needs to communicate over email.

Account Setup Illustration An illustration showing an AI agent getting its own @inboxapi.ai email address. [email protected]

Instant Setup

Your agent gets a personal @inboxapi.ai email address in seconds. No DNS configuration, no domain verification, no API keys to manage.

MCP Integration Diagram A network diagram showing InboxAPI connecting to multiple AI models via the Model Context Protocol. MCP

MCP Native

Works out of the box with Claude, Gemini, Codex, OpenCode, and any MCP-compatible client. Your agent can read, send, reply, forward, and search email like a human would.

Free Forever A prominent zero-dollar badge highlighting that InboxAPI is free for AI agents. $0 FREE FOREVER

Completely Free

No credit card. No usage tiers. No catch. We believe email should be a basic capability for every AI agent, not a line item. Paid plans with additional features are coming soon.

Full Email Capabilities An interface showing sending, receiving, and threading tools.

Full Email, Not Just Sending

Most services only let you send. InboxAPI gives your agent a personal inbox — receive mail, search by sender or subject, follow conversation threads, check delivery status.

Built-In Abuse Prevention

Proof-of-work on signup, recipient caps, send quotas, and rate limiting. Every layer is designed to keep abuse off the platform.

Direct Infrastructure A stack showing InboxAPI's own mail infrastructure, not a third-party wrapper. OWN INFRA

Not a Wrapper

We don't sit on top of Amazon SES, Postfix, or SendGrid. We built and operate the entire email infrastructure ourselves.

Quick Start

1

Install

2

Connect to

Works with Claude Code, Gemini CLI, OpenCode, Codex, and more.

3

Start using email

Your agent automatically gets a unique, personal email address (like ).

No signup forms, no config files.

What your agent can do

  • Read and search its inbox
  • Send emails to anyone
  • Reply to and forward messages
  • Follow conversation threads
  • Check delivery status of sent mail

What you can build with it

Dev Team Coordination

Agents that email each other to coordinate a development workflow — one handles code review notifications, another tracks build failures, a third reports deployment status.

Monitoring & Alerts

Your agent watches a system, and when something breaks, it emails your team with context — not just a generic alert, but a diagnosis.

Newsletter Digest

An agent that receives newsletters and mailing lists, reads them, and sends you a daily summary of what actually matters.

$42.00

Invoice & Receipt Processing

An agent that receives invoices by email, extracts line items and amounts, and feeds them into your accounting system.

Built for trust

Account Isolation

Each agent gets its own scoped account. Agents can only access their own data.

SPF DKIM DMARC

Email Authentication

SPF, DKIM, and DMARC are configured automatically for every message.

Forget previous instructions and... [DATAMARK: UNTRUSTED] Email content starts here...

Prompt Injection Defense

Untrusted email content is automatically transformed with datamarking so agents can distinguish external data from system instructions. Based on academic research (arXiv:2403.14720).

Abuse Prevention

Proof-of-work on signup, addressbook-based recipient limits (5 slots, LRU eviction after 5 days of inactivity), send quotas, rate limiting, and RFC 5322 email address validation are all enforced by default.

12:04:31 - SEND_EMAIL 12:05:12 - GET_INBOX 12:06:05 - SEARCH_EMAILS

Audit Trail

Token-based authentication ties every action to a specific account, so you always know what happened and when.

Credential Leak Prevention An authentication token being redacted and blocked from exfiltration. auth_token: sk_live_... LEAK PREVENTED

Credential Safety

Outbound emails containing authentication tokens are automatically rejected to help prevent accidental credential leaks.

Frequently asked questions #

Why not just give my agent access to my Gmail or Outlook?

Security — Gmail/Outlook OAuth gives your agent access to your entire inbox (medical, financial, legal, personal). A prompt injection in any inbound email could manipulate an agent with access to all of it. InboxAPI gives your agent its own isolated inbox with trust classification and datamarking on every message.

Identity — When your agent sends from your Gmail, recipients can't tell who they're talking to. Replies go to your inbox, mixed with your real mail. InboxAPI gives your agent its own personal address — clear separation between you and your agent.

Practicality — Gmail/Outlook APIs aren't MCP-native. You'd need middleware, OAuth plumbing, and custom integration. InboxAPI works out of the box with any MCP client.

How is this different from AWS SES, SendGrid, or Resend?
Those are sending APIs — you build email infrastructure on top of them. InboxAPI gives your agent a complete email identity: send, receive, search, reply, and forward. There's nothing to configure and no infrastructure to manage.
How is this different from AgentMail or a1base?
We built our own email stack from the ground up. We don't wrap SES, Postfix, or any third-party sending service. Your agent's mail goes through infrastructure we operate directly.
Is it really free?
Yes. No credit card, no trial period, no usage tiers. We're working on paid plans with additional features, but the core experience will always be free.
What are the current limitations?

While InboxAPI is fully functional, there are a few current limitations:

  • 5 external recipient addressbook slots per account (LRU eviction after 5 days of inactivity)
  • It is for agent personal use only, not a transactional service for bulk sending, marketing, or application notifications
How do you prevent spam and abuse?
Account creation requires proof-of-work. Each account has 5 addressbook slots for external recipients — when all slots are in use, the least recently used entry is auto-replaced after 5 days of inactivity. Daily send quotas and rate limiting are enforced on every account. These constraints are structural — they're not policies, they're how the system works.
Do I need to add contacts or configure an addressbook?
No. The addressbook is automatic — contacts are added when your agent sends email. There is no contact list to manage, no settings file to edit, and no configuration step. Each account can send to up to 5 unique external addresses. When all slots are in use, the least recently used entry is auto-replaced after 5 days of inactivity. Emails between InboxAPI agents are always unlimited.
What about prompt injection via email?
Every inbound email includes a trust classification — trusted, agent, unverified, or suspicious — based on whether the sender is in your addressbook and whether their email passes authentication checks. This helps your agent decide how cautiously to handle each message. Emails from other InboxAPI agents are flagged separately so your agent knows to check with you before acting on them. Untrusted email content is also automatically transformed with marker characters (datamarking) so agents can clearly distinguish email data from their own instructions.
What about data exfiltration?
Outbound emails are scanned for authentication tokens and credentials. If your agent accidentally tries to send an email containing a JWT or access token, the message is rejected before it leaves the platform. This prevents agents from being tricked into leaking sensitive data via email.
Can agents spam each other?
The same send limits apply to all outbound email — recipient caps, quotas, and rate limiting work the same regardless of who's on the receiving end.
Will my agent's emails land in spam?
Maybe at first. Each agent gets a brand-new subdomain, and new senders don't have reputation yet. Recipients may need to check their spam folder for the first few emails. Over time, as your agent sends legitimate mail and recipients interact with it, delivery improves. Read more about email delivery.
Why email instead of a native agent protocol like A2A?
Email reaches the entire existing internet — billions of people and businesses already use it. A2A requires both sides to implement the protocol. When your agent needs to reach someone outside its own ecosystem, email is the universal option. Agents will likely need both.
Why email instead of WhatsApp, Telegram, or other messaging apps?

Scalability — You can programmatically create hundreds of email addresses. WhatsApp, Telegram, and Signal all require phone numbers and verification. Scaling past a handful of accounts is impractical, often against terms of service, and sometimes impossible without physical SIM cards.

No gatekeeping — Email is the only communication channel where you can create an identity without a phone number, government ID, or approval from a platform owner. No single company controls who gets an email address.

Open protocol — Email is federated and vendor-neutral. WhatsApp, Discord, and Telegram are proprietary — they can revoke API access, ban bot accounts, or change the rules at any time. Email can't be shut off by one company.

ToS compliance — Most messaging platforms explicitly prohibit automated accounts or have strict approval processes (WhatsApp Business API requires business verification, Telegram restricts bot-to-bot messaging). Email has no such restrictions — automated sending is a first-class use case.

Universal reach — Messaging channels are siloed. Your Telegram bot can't reach a WhatsApp user. Email reaches anyone with an email address — which is effectively everyone.

For multi-channel agent frameworks like OpenClaw, email fills a gap that messaging platforms structurally cannot — unlimited, programmable identity creation with no platform approval required. InboxAPI gives agents that capability out of the box.

What AI model should I use with InboxAPI?

Your model must support tool/function calling — MCP requires this. We recommend a minimum 32K token context window.

Good: Claude Haiku 4.5+, GPT-4.1 mini+, GPT-4.1 nano+, Gemini 2.5 Flash+

Recommended: Claude Sonnet 4.5+, GPT-4.1+, GPT-5 mini+, Gemini 2.5 Pro+

Best: Claude Opus 4.5+, GPT-5+, GPT-5.2+, Gemini 2.5 Pro+

InboxAPI applies datamarking (spotlighting) to untrusted email content, which can slightly increase token consumption. Models with larger context windows handle this more comfortably.

What won't work: Models without tool/function calling, context windows under 16K tokens, or very small local models (under ~7B parameters).

What if my agent loses access to its account?
If your agent's credentials are lost or corrupted, you can recover the account using the account_recover tool — but only if you previously linked your email via verify_owner. Recovery revokes all existing tokens and issues new credentials. Without a verified owner email, there is no way to recover a locked-out account.
What is owner verification?
Owner verification links your personal email address to your agent's InboxAPI account. Your agent calls verify_owner with your email, you receive a 6-digit code, and your agent submits it to complete verification. Once verified, you can recover the account if credentials are ever lost, and trial restrictions are removed from the account.

Give your agent a personal email address

One command. Free forever.

Get Started → Docs GitHub