Tempx developer documentation

SMTP capture gateway — get test mail in

The primary integration for applications: point your application's mailer at the gateway and every message is captured into the credential's paired inbox — original recipients preserved, nothing ever relayed to a real person.

Stack-specific setup (Laravel, Rails, Django, Node, n8n) is on the integrations page; the concept is covered at /smtp-testing.

MCP server — read, search and wait, for AI agents

The primary integration for AI agents and automated verification. Agents get their own inbox through the Model Context Protocol. Preferred auth is browser pairing (OAuth 2.1 with PKCE — the user approves one inbox, no secret is pasted); everywhere else, use an API key (tmcp_) as the Bearer token — the same key that also covers SMTP and Resend capture. Each key is scoped to exactly one inbox, expires on a chosen schedule, and can be revoked in one click.

Endpoint: https://tempx.uk/mcp (streamable HTTP). Claude Code connects with `claude mcp add --transport http tempx https://tempx.uk/mcp`; pairing guides for Claude, ChatGPT and Z.ai are on the Connect Claude page.

API keys — one key for MCP, SMTP and Resend capture

Most integrations start with one API key, created in the account at tempx.uk/account#mcp (the “API keys” tab). The key carries tmcp_ prefix, is scoped to exactly one inbox you select, and works across three surfaces at once. Keys are shown exactly once at creation, stored server-side only as a hash, and support read / search / wait / send permissions with an expiry of 1, 7, 30, 90 days or none. Revoking the key — or letting it expire — cuts off MCP, SMTP and Resend capture simultaneously.

Prefer not to hold a key at all? The MCP server also supports browser pairing via OAuth 2.1 (used by Claude and ChatGPT connectors): the user signs in at tempx.uk and approves one inbox — no secret is pasted anywhere.

Resend-compatible capture endpoint

Apps already using the Resend SDK can capture their sends without touching the mailer: point the SDK's base URL at Tempx and swap the API key. Requests are parsed in Resend's send-email shape, and the message is captured into the key's inbox — with Resend-shaped success and error bodies, so the SDK parses the response natively. The same adapter contract is how future providers (SendGrid, Mailgun, Postmark) will be added.

POST /resend/emails

Capture one outgoing test message in Resend send-email format.

Auth: Authorization: Bearer tmcp_… (or the SDK's apiKey field set to the key). The send permission is required. · Rate limit: 30 requests / 5 minutes per key

Parameters

• SDK setup (Node): new Resend({ apiKey: process.env.TEMPX_KEY, baseUrl: "https://tempx.uk/resend" }). Everything else in the integration stays unchanged.
• The message is never delivered — from/to are preserved on the captured copy for assertions.
• A missing or wrong-scope key returns Resend-shaped errors: missing_api_key (401) and missing_scope (403).

curl -X POST https://tempx.uk/resend/emails \
  -H "Authorization: Bearer tmcp_YOUR_KEY" \
  -H "content-type: application/json" \
  -d '{"from":"app@yourdomain.test","to":"user@example.net",
       "subject":"Reset your password","html":"<p>Token: 123456</p>"}'

Response: Resend-shaped success: { id } for the captured message; provider-shaped error bodies on failure.

Setup walkthrough with Node and curl examples: the Resend testing guide on the blog, or the SMTP integration page for mailer-based setups.

Security model: choose the right inbox

Two inbox kinds share one product, and the difference is who holds the key. Named inboxes are public by design — this is the classic public-inbox model, chosen for zero-friction testing, and it is documented in the app, the FAQ and the Terms. Private random inboxes are the security boundary for everything else.

Never point accounts that matter at a named inbox — password resets and two-factor mail sent to a guessable name can be read by strangers, and the Terms of Service prohibit using Tempx for exactly that. Opening, harvesting or enumerating inboxes belonging to other people is a misuse of the service and may be unlawful. Rate limits blunt bulk scraping: 240 reads/min per source, plus a distinct-address cap — roughly 150 different public inboxes per hour per source — that specifically blunts name-enumeration. Cloudflare bot management sits in front of everything.

The product API — first-party, not a public developer API

Tempx's own clients talk to the site over a REST surface: the web app reads and clears inboxes (GET/DELETE /api/inbox), creates private inboxes (POST /api/mailbox, Turnstile-gated), and manages accounts over session-cookie endpoints; the Chrome and Firefox extensions poll GET /api/inbox — ?address= for named inboxes, an Authorization: Bearer header for private ones. That surface exists to power these first-party clients and stays working for them, but it is an internal product contract, not a public developer API. Official integrations should use the surfaces above: SMTP capture to get mail in, MCP to read, search and wait. Scripts you own that need raw JSON should authenticate with a private inbox's Bearer token instead of building on public named inboxes.

Because the contract of these endpoints is with Tempx's own clients, they can change or tighten without notice. The supported developer surfaces — SMTP capture, MCP and the Resend adapter — are documented to a different standard: they are stable, versioned by this reference, and safe to build on.

Public stats

Aggregate, anonymous usage counters — handy for status pages.

GET /api/stats

Weekly aggregate counters (inboxes created, emails received).

Auth: None. · Rate limit: Cached at the edge

• Aggregate counts only — never per-address data.

curl -s https://tempx.uk/api/stats

Response: { weekly: { inboxesCreated, emailsReceived, … } }

Limits and rules that apply to everything above

Automated abuse — inbox harvesting, ban evasion, bulk account creation — is prohibited by the Terms of Service and blocked by rate limits. Report abuse to abuse@tempx.uk.