Test accounts & the agent inbox

Most real flows start behind a login. Reflow supports three strategies; pick per flow.

Strategy 1 — fresh signup every run (recommended)

The flow signs up as a brand-new user each time. Most faithful to a real first-run experience, zero state leakage between runs, and it exercises your signup path for free.

The catch is email verification — solved by the agent inbox below.

Strategy 2 — seeded credentials

For flows that need an existing account (admin views, data-heavy dashboards), store credentials as flow variables:

# .reflow/flows/admin-report.md frontmatter
variables:
  - ADMIN_EMAIL
  - ADMIN_PASSWORD

Values are set per-team in the dashboard (encrypted at rest, never logged, injected only into runs that declare them) and referenced in steps as process.env.ADMIN_EMAIL. Rotate them like any other secret.

Sessions are never reused across runs — every run starts with a cold browser profile.

Strategy 3 — magic links & OTP via the agent inbox

Every run gets a disposable email address:

run-<run-id>@inbox.reflow.io

Mail to that address is delivered to the run, and the agent can read it with its inbox tool — so email-verification signups, magic-link logins, and OTP codes work without any test-mode backdoor in your app:

1. Flow fills the signup form with run-<run-id>@inbox.reflow.io.
2. Your app sends the verification email.
3. The agent reads the inbox, extracts the link or code, and continues.

The inbox is created at run start and destroyed with the run’s retention window. Messages appear in the run timeline alongside screenshots, so you can see exactly what your app sent.

What about third-party auth?

OAuth providers (Google, GitHub) gate sign-ins behind bot detection and are deliberately out of scope. Give flows a first-party path: email/password or magic link in your test environment.