Email.For agents.

Any agent that can make authenticated HTTP requests through a tool, API action, SDK or configured connector can use this API design. That includes OpenAI Codex, tool-enabled ChatGPT, Anthropic-powered agents, Claude Code, Hermes Agent, OpenClaude, OpenClaw and custom harnesses. Plain chat without tool access needs a connector first. This is protocol compatibility, not a claim of tested native integrations or vendor endorsement.

Yes on the automated path: an authorized HTTP client can establish account control, request a funding quote, settle a supported x402 payment, receive scoped credentials, create an inbox and use it. No browser checkout is required. The agent must actually have authorized payment tooling; a model name alone does not provide a wallet. Account verification, sending limits and abuse policies still apply.

You can create the account and buy prepaid credit using a card, Bitcoin, ETH, SOL or USDC. Give your agent a scoped mailbox credential, not your wallet or card access. The agent can then send and receive over HTTP using the balance you funded.

Yes. Every payment method funds credit before usage begins. Email and retained storage consume that credit; bundles are purchased upfront from the balance. No after-use invoice. New billable work pauses when available funds are insufficient. Card disputes and payment reversals can still require account review.

Buy a bundle using prepaid credit for a lower email-unit rate. If you opt into recurring renewal, a new period starts only after sufficient funded credit covers the price. Unused bundle units expire at period end. Extra units require explicit permission and sufficient prepaid credit. Automatic top-up is off unless separately authorized; a funding payment does not automatically purchase a bundle.

No. It can fund one account balance that pays for many messages. Authenticate account control separately from payment. Credit payment once after verified settlement, then issue scoped credentials for ordinary HTTP mail requests. x402 is a payment protocol, not a coin; supported assets depend on the scheme and network.

Yes, after verifying ownership and configuring the required routing and sender-authentication records. We operate the intended mail delivery infrastructure directly, without a third-party sending service. Receiving servers still decide whether to accept a message or place it in spam.

New outgoing submissions pause. Incoming messages that cannot be durably accepted within available credit or storage limits receive a clear SMTP response rather than being acknowledged and silently discarded. Already accepted work has its cost reserved. Existing stored mail remains readable during a recovery window; retention, export and deletion follow the account policy. No invisible overdraft.

No. Credit controls spending; trust and abuse controls govern sending. Limits apply at the customer level across all its agents. Buying more credit or creating more inboxes does not bypass those controls.

No. This is email for agents, not an agent runtime. Model inference and agent execution remain with your chosen harness. Mail is stored even when the agent is offline; notifications let your system decide when to run it.