Registration and OTP
Create one address per run, submit it through the product, and assert that the expected verification message arrives.
Developers & QA
Temporary email for developers and QA teams.
Give each signup, verification-code, magic-link, or password-reset test its own receiving address—then inspect the message through a credential-scoped API.
API credentials are currently operator-issued. Access is not self-service, and message delivery is not guaranteed.
Use the right testing layer
A real receiving boundary for the tests that need one.
Most mail behavior belongs in fast unit tests with a fake transport. Use a temporary inbox for the smaller set of integration and end-to-end checks where actual inbound delivery matters.
Password-reset flows
Check the recipient, sender, subject, expiry language, and reset URL without sharing a long-lived team mailbox.
Parallel CI jobs
Keep messages attributable by provisioning a separate credential-owned inbox for each scenario or worker.
Reliable test pattern
Bound the wait. Keep the failure useful.
A fixed sleep is either too short on a slow day or longer than necessary on a fast one. Poll modestly, stop at a clear deadline, and report what failed.
Read the developer testing guide-
01
Create
Provision an inbox with an operator-issued credential that has the inbox:create ability.
-
02
Trigger
Run the same signup, OTP, or reset action that a user would perform.
-
03
Poll
List messages with inbox:read until the expected stable subject appears or the deadline expires. Back off between requests and honor Retry-After.
-
04
Inspect
Retrieve the selected message and assert its recipient, sender, important copy, code, or URL. Treat every body and attachment as untrusted input.
-
05
Expire
Let the inbox and messages age out after the test. The standard deployment default is about 60 minutes.
What it can verify
The message crossed an inbound email boundary.
- • A message reached the isolated receiving address.
- • Stable headers, recipient, subject, bodies, and attachment metadata match the scenario.
- • Your product-generated code or link is present and behaves as expected.
What it cannot promise
Delivery, placement, and client rendering are separate questions.
- • SMTP can be delayed or rejected, and third-party sites may block temporary domains.
- • Receiving a message does not prove inbox placement with Gmail, Outlook, or another provider.
- • A browser preview is not a substitute for testing across real email clients and devices.
Ready to evaluate the private beta?
Start with the endpoint reference and Playwright example. If the boundary fits your test suite, request an operator-issued credential through the contact page.