Skip to content

Mailbox testing and test accounts

Every run starts with a cold browser profile. Choose between a fresh account created during the flow and a seeded account stored in your test environment; sessions do not leak from one run to the next.

Reflow provisions one disposable inbox for the run. Its address has a high-entropy hexadecimal local part, for example <random-hex>@inbox.reflow.io, and is available to executable steps as ${MAILBOX}.

Use the address in the application under test, wait for the verification message, and open the matching link:

---
name: New user verifies their account
url: /signup
---
### Create an account
```rfl
open /signup
fill label="Email" ${MAILBOX}
fill label="Password" ${SIGNUP_PASSWORD}
click role=button name="Create account"
```
### Verify the email address
```rfl
wait for email from~="noreply@" subject~="Verify" timeout=60s
open email link href~="/verify" subject~="Verify"
expect page url~="/welcome"
```

The mailbox is bound to the run, so the same pattern works for magic links and password-reset journeys without a test-mode backdoor in your application.

fill <target> email code extracts a code from the selected message and fills the field deterministically:

open /login
fill label="Email" ${MAILBOX}
click role=button name="Send code"
wait for email subject~="code" timeout=60s
fill label="Verification code" email code pattern~="\d{6}" subject~="code"
click role=button name="Verify"
expect page url~="/account"

The email matchers are documented in the RFL reference.

For an existing admin or data-heavy account, set credentials in the team’s dashboard settings. They are encrypted at rest, injected only when a run is claimed, and referenced directly in step bodies:

open /login
fill label="Email" ${ADMIN_EMAIL}
fill label="Password" ${ADMIN_PASSWORD}
click role=button name="Sign in"
expect page url~="/admin"

Do not add a variables: key to flow frontmatter and do not use process.env.ADMIN_EMAIL in RFL. Values are substituted at the last moment, never logged, and redacted back to ${NAME} placeholders in execution errors. Rotate them like any other secret.

The MCP surface exposes four run-scoped mailbox tools:

  • get_mailbox — get or create the run’s mailbox and return its address.
  • wait_for_message — wait for the next matching message.
  • list_messages — list delivered messages without waiting.
  • read_message — read one message with its body, links, and codes.

See the MCP reference for the OAuth connection and run loop.

Third-party OAuth providers such as Google and GitHub commonly add bot detection and are outside this contract. Give browser flows a first-party email/password, magic-link, or OTP path in the test environment.