Email testing in every language

The official Python client wraps the REST API in two calls: open an inbox, wait for the code. Works in pytest, unittest, Robot Framework or a plain script.

Zero dependencies, built on the runtime's own fetch. Drop it into Jest, Vitest, Playwright, Cypress or a Node script.

The same package as JavaScript, with types shipped in the box: Message, CreateInboxOptions, WaitOptions and typed errors.

Built on java.net.http, no HTTP dependency of its own. Made for Selenium and JUnit suites that need a real address per test.

No gem yet, and none needed: the API is six endpoints and Ruby ships net/http. Copy the helper below into spec/support and you are done.

No Composer package required: the helper below uses the bundled cURL extension. Works the same in PHPUnit, Pest or Laravel Dusk.

Standard library only: net/http and encoding/json. One small client type covers every endpoint you need in a test.

HttpClient plus System.Net.Http.Json — no package to install. Fits xUnit, NUnit and SpecFlow suites driving Selenium or Playwright.

Every endpoint in one terminal. Useful for smoke checks, CI shell steps, and for seeing exactly what your language client sends.

Give every Playwright test its own real inbox, read the verification code your app actually sent, and finish the signup flow end to end.

Read real verification emails from a Cypress test by moving the API calls into a Node task, where network access belongs.

Fill a signup form with a real address, then type the code that really arrived — in Java or Python, next to the WebDriver calls you already have.

A conftest fixture that gives every test its own inbox and cleans up afterwards, whether the test passed or not.

Open an inbox in beforeEach, delete it in afterEach, and give Jest a timeout long enough for real mail to arrive.

The same flow as Jest with typed fixtures: Vitest picks up the client's TypeScript types with no extra setup.

Keep the mailbox out of the feature file: the scenario says a user signs up and enters the code, the step definitions do the work.

Wrap the Python client in a small keyword library and your suites get New Inbox and Wait For Otp as ordinary Robot keywords.

Hooks in wdio.conf.js open and close the inbox; the spec just reads the address off the global.

TestCafe fixtures map cleanly onto inbox lifecycle: beforeEach opens one, afterEach deletes it.

Chain three requests — create an inbox, trigger your flow, read the code — with the address carried between them in a collection variable.

Give every workflow run its own inbox, pass the address to the suite as an environment variable, and sweep it up even when the job fails.

The same per-run inbox pattern in .gitlab-ci.yml, with the key stored as a masked CI/CD variable and teardown in after_script.

Run the MailFlat MCP server and any Model Context Protocol client gains real inbox tools: open an address, wait for the one-time code, send mail, clean up.

Add the MailFlat MCP server to Claude Desktop so Claude can open a real inbox, read the verification code your app just sent, and clean up afterwards.

Give Cursor's agent a real inbox: add the MailFlat MCP server to your project or user config and it can register test accounts and read the codes on its own.

MailFlatToolkit turns the Python SDK into LangChain tools, so an agent can open inboxes and read verification codes as part of its normal tool loop.

mailflatToolSuite() spreads ready-made inbox tools into any Vercel AI SDK call, so the model can create an address, wait for the code and finish a signup on its own.

There is no MailFlat package for the OpenAI Agents SDK and none is needed: attach the MCP server, or wrap the Python client in two function tools.

The full pattern for an autonomous signup: one labelled inbox per service, a real verification code, an audit trail, and the rules about where not to point it.

Every endpoint, body field, error and rate limit, with the encrypted-inbox behaviour spelled out.