Disposable inboxes over HTTP

Quickstart

# 1. get an inbox (no auth needed)
curl -sX POST https://dev-mail.com/v1/inboxes
# {"address":"[email protected]","token":"3f9c...","expires_at":"...","ttl_seconds":...}

# 2. wait for the code and read it back
curl -s -H "Authorization: Bearer $TOKEN" \
  "https://dev-mail.com/v1/inboxes/$ADDRESS/code?wait=60"
# {"found":true,"code":"309154","from":"Acme","subject":"Confirm your email",...}

That is the whole flow. Step 2 blocks until the code arrives, so you do not need a polling loop of your own.

Wiring this into a test suite instead? The Playwright and Cypress guides carry the same flow as a fixture and a pair of custom commands.

Basics

Endpoints

curl -s https://dev-mail.com/v1/domains
{"domains":["diyapn.com", "..."],"count":4,"paid_domains":["winmail.cfd", "..."]}

curl -sX POST https://dev-mail.com/v1/inboxes \
  -H "Content-Type: application/json" \
  -d '{"domain":"diyapn.com","style":"american"}'

curl -s -H "Authorization: Bearer $TOKEN" \
  "https://dev-mail.com/v1/inboxes/$ADDRESS/messages?since=1757000150"

curl -s -H "Authorization: Bearer $TOKEN" \
  "https://dev-mail.com/v1/inboxes/$ADDRESS/code?wait=60"

Errors

Errors come back as {"error":{"code":"...","message":"..."}} with a matching HTTP status.

Out of inboxes? Pay for the next one, no account

A 429 is a dead end for an agent: it has no browser to go buy a plan with, so all it can do is back off, and backing off does not produce the inbox it needs right now. So POST /v1/inboxes answers 402 with a price instead, using the x402 protocol.

$0.003 per inbox, paid in USDC on Polygon (eip155:137). No signup, no API key, no card. Reading, polling and long-polling stay free, so one payment covers a whole verification run rather than each poll.

Steady heavy use is cheaper on a Pro licence than per inbox. Both work without an account; the licence just raises the free ceiling instead of charging each time.

MCP server for AI agents

Dev-Mail speaks the Model Context Protocol at https://dev-mail.com/mcp over Streamable HTTP. It is stateless and needs no auth, so an assistant can complete a signup flow on its own: create an inbox, watch it, read the code back.

Because the server keeps no session, the token from create_inbox is passed back on each later call.

claude mcp add --transport http dev-mail https://dev-mail.com/mcp

Or in an MCP client config file:

{
  "mcpServers": {
    "dev-mail": {
      "type": "http",
      "url": "https://dev-mail.com/mcp"
    }
  }
}

A full signup, end to end

#!/usr/bin/env bash
set -euo pipefail

inbox=$(curl -sX POST https://dev-mail.com/v1/inboxes)
address=$(echo "$inbox" | jq -r .address)
token=$(echo "$inbox" | jq -r .token)

echo "signing up as $address"
# ... trigger the signup on the site under test, using $address ...

result=$(curl -s -H "Authorization: Bearer $token" \
  "https://dev-mail.com/v1/inboxes/$address/code?wait=60")

if [ "$(echo "$result" | jq -r .found)" = "true" ]; then
  echo "code: $(echo "$result" | jq -r .code)"
else
  echo "no code arrived in 60s" >&2; exit 1
fi

Fair use

The API is open because asking for a key would defeat the point. In exchange: stay inside the rate limits, back off when you see a 429, and do not use Dev-Mail to create accounts in bulk or to evade a service's own terms. Inboxes are disposable — nothing here is durable storage, and mail is purged as addresses are recycled.