Auth and Messages
Test OTP, email inboxes, static accounts, SMS, and protected previews.
Many important journeys leave the browser: magic links, OTP codes, welcome emails, receipts, SMS verification, and password resets. Autonomy keeps those messages attached to the same run as the browser or mobile session.
Inboxes
Generated inboxes are useful for disposable signup, invite, and receipt checks. Static inboxes are better when an auth provider rejects disposable domains, when a staging tenant has seeded users, or when a third-party system must approve a fixed address.
Email verification mechanisms
Configure how the agent gets through email verification screens in Settings → Integrations → Email Verification (workspace default), or per environment from the environment's settings. Environment overrides win over the workspace default.
Hosted inboxes (default)
Autonomy mints a throwaway address per run and reads the real email — OTP codes and magic links both work, with zero setup. Use this unless your app restricts which email domains can sign up.
Test mode (static code)
For apps that only accept approved domains — for example a dev environment that rejects every address outside your corporate domain. Your backend treats templated addresses as test users with a fixed verification code, and Autonomy serves that code without any real email delivery. This is the same pattern as Clerk +clerk_test addresses (fixed OTP 424242) and Firebase fictional phone numbers.
- Address template — e.g.
qa+{token}@yourcompany.com.{token}becomes a random slug per run so parallel sign-ups never collide. A template without{token}is rejected unless fixed test addresses exist, because a fixed address breaks the second sign-up run with "email already registered". - Test addresses — fixed accounts your test cases log into with stored credentials. The static code applies to these too, so a login flow that triggers an email OTP passes without any inbox.
- Static code — the fixed code your backend accepts for these addresses. Stored write-only, like other secrets.
Your backend's one-time change: in non-production, treat addresses matching the template as test users — accept the fixed code and skip the real send.
Test mode serves codes only. Flows that verify via magic link need real delivery — use hosted inboxes or your own domain.
Your domain (bridge)
Real delivery on a domain you own — codes and magic links work, on an allowlist-approved domain, with no backend changes. Autonomy mints short addresses like r-a1b2c3d4@qa.yourcompany.com per run.
Setup (workspace admin, in the Email Verification settings):
- Add a dedicated subdomain (e.g.
qa.yourcompany.com) — its catch-all forward will send all its mail to Autonomy. - Prove ownership: add the TXT record shown in settings (
_autonomy-challenge.qa.yourcompany.com→autonomy-verify=…), then click Verify. - Forward the mail: set a catch-all forward for the subdomain to your workspace ingest address (shown in settings). Works with Cloudflare Email Routing, Google Workspace routing, or Microsoft 365 transport rules. If your provider sends a forwarding-confirmation email to the ingest address, its confirmation link appears in the settings panel.
- Activate: send any email to
test@qa.yourcompany.com. The first forwarded email proves the bridge and activates it automatically.
Fixed test accounts on the bridge domain can be listed as test addresses — their verification emails are readable by every run in the scope, so login-triggered OTPs and magic links work for stored-credential accounts too.
Runs fail with an actionable error while the bridge is unverified or inactive — there is no silent fallback to hosted inboxes, because a hosted address would be rejected by the same domain allowlist that made you configure the bridge.
Choosing a mechanism
| Situation | Mechanism |
|---|---|
| App accepts any sign-up address | Hosted inboxes |
| Magic-link flows, unrestricted domains | Hosted inboxes |
| Sign-up restricted to your corporate domain, codes only | Test mode with an address template |
| Fixed test accounts + email OTP on login | Test mode with test addresses |
| Restricted domains and magic links, or production-grade deliverability | Your domain |
OTP
Autonomy can wait for email OTP messages, extract the code, and continue the flow. Keep OTP waits narrow by naming the sender, subject, and expected code shape so the run does not accidentally use an old or unrelated message.
SMS
Use SMS checks for verification flows that cannot be exercised through email. Treat SMS numbers as test resources: document who owns them, which environments can use them, and when they should be rotated.
Protected previews
For protected previews, document the bypass token or preview password as an environment variable, not in the test case body.
| Variable | Required | Description |
|---|---|---|
| AUTONOMY_PREVIEW_BYPASS | No | Bypass token or password for protected previews. |
| AUTONOMY_STATIC_TEST_EMAIL | No | Static inbox address for providers that reject disposable email. |
Troubleshooting
No message arrives
Check the recipient address or number, sender restrictions, environment-specific email settings, and whether the provider suppresses messages for test domains.
The wrong code is used
Tighten the sender, subject, and timestamp constraints. OTP checks should wait for a new message created during the run, not the most recent message in the inbox.