The email API an agent can buy itself

Why an agent cannot use a normal email API

Sign-up forms are built for people. They want an address somebody can read mail at, a password somebody can remember, a card in somebody’s name, and increasingly a checkbox proving you are not the thing we are selling to. A program can be given credentials a human obtained for it, but it cannot obtain them, which means every autonomous system that needs to send email has a person wired into its critical path.

Pony removes the person by making payment the only account-creation step, and by making payment something a program can do. There is no form to fill in because there is no form.

What an agent needs

• An HTTP client. That is the whole SDK requirement — there are no client libraries.
• A wallet holding USDC on Base, funded with at least the price of the plan.
• The ability to sign an EIP-3009 transferWithAuthorization message. Every mainstream wallet library can do this.

It does not need an email address, a password, a browser, a card, or a human on standby.

The exchange, in five steps

The protocol is x402 version 2. The agent never has to guess a price: a refusal quotes every plan on sale, so it chooses the window it wants rather than the one we would have chosen for it.

• Send the email with no credentials. The answer is 402 Payment Required with a PAYMENT-REQUIRED header.
• Base64-decode that header. It carries one entry per purchasable plan, each naming the scheme, the chain, the token, the destination address, the exact amount in atomic units and a timeout. An entry identifies its plan by amount rather than by name, so match it against GET /plans, which needs no key.
• Sign one USDC authorisation for exactly that amount, to exactly that address.
• Post it to POST /plans/{plan}/purchase in a PAYMENT-SIGNATURE header. The response carries the API key, the plan, the sends included, the expiry, the transaction and a sending address that already works. Sending that header anywhere else does nothing: the purchase route is the only one that reads it.
• Retry the original send with that key. It goes out.

The wire documents for all five, copied from the fixtures the API is tested against, are on the landing page. Every endpoint, header and error name is in the API documentation.

How an agent finds any of this

Four surfaces, all readable before anything is called and none of them requiring a key:

GET  /plans                     every plan, priced, as JSON
GET  /llms.txt                  the whole integration, in one file
GET  /skills/openai.json        function definitions for tools[]
GET  /skills/gemini.json        the same surface, as declarations
MCP  api.pony.email/mcp         the same API, mounted as tools

The catalogue is on api.pony.email; the four files are on this host.

The MCP server is the shortest path for a client that already speaks it. Two of its five tools need no API key at all, and they are exactly the pair that takes a caller from nothing to a key: read the plans, then buy one.

What the agent is exposed to

The amount and the recipient are inside the authorisation the agent signs, so neither can be altered afterwards. Settlement runs through a facilitator, which means Pony never holds a key and never verifies a signature itself.

Payment is idempotent on the payer and the nonce. An agent that retries a purchase it is not sure completed gets the original result back, including the same API key, rather than being charged a second time — which matters more here than usual, because the caller deciding to retry is a program with no way to ask.

Nothing renews on its own. When the window is spent the next send answers 402 again with a fresh quote, so an agent that can handle the first refusal can handle every one after it. That is the whole lifecycle: there is no subscription to cancel and no invoice to dispute. The FAQ covers the rest, and the terms govern what the key entitles its holder to.