Testing a sign-up flow means receiving real mail somewhere, and the usual options are bad: a shared team mailbox nobody cleans, a personal address that ends up in the staging database, or a mail catcher that never proves your MX path actually works. Throwaway inboxes with an HTTP API sit in between.
Use Choose your own to create predictable addresses such as signup-happy-path or reset-expired-token, so a failing run tells you which case broke without a lookup table. Names are released when the inbox expires, so a suite can reuse them on the next run.
Plus-addressing works too: mail to name+anything@ lands in the name@ inbox, which is handy for testing how your own code handles tagged addresses.
The API is plain JSON with no authentication. POST /api/mailbox returns an address; GET /api/mailbox/:address/messages lists what arrived; GET /api/mailbox/:address/messages/:id returns the sanitized HTML, the plain-text body, the attachment metadata and any detected verification code as a field you can assert on directly.
For tests that would otherwise poll, GET /api/mailbox/:address/events is a Server-Sent Events stream that pushes a message event the instant mail is delivered. Full route list is in the project README.
Because delivery arrives over SMTP on port 25 from your application's actual mail provider, a passing test proves your DNS, your provider and your templates all work together — which a local mail catcher listening on 1025 cannot tell you.
Bear in mind the inboxes are public to anyone who knows the address and are wiped on expiry, so this belongs in staging and CI, never in production flows carrying customer data.
The obvious check is that a message arrived at all, but the useful ones go further: that the subject matches the template you expect, that the detected verification code is the one your application generated, and that the confirmation link contains a token your test can then exchange.
The sanitized HTML is also worth asserting on. If the response strips something your template depends on, that is a signal your template is relying on markup that real mail clients will drop too — Gmail and Outlook are no more permissive than the sanitizer here.
No. Every endpoint is open and unauthenticated, protected only by per-IP rate limits, because there is nothing private to protect behind a key.
Yes. The whole service is open and runs from a single docker compose file with an in-memory or Redis store — useful when you want inboxes that never leave your own network.
The most recent hundred, with the oldest dropped beyond that, and everything removed when the mailbox expires.