Inboxes and phones
Receive verification emails, magic links, SMS codes and receipts in a run, and see every message it received.
Many journeys leave the browser: magic links, one-time codes, welcome emails, receipts and SMS verification. Autonomy gives a run its own inboxes and phone numbers, and keeps every message with the run that received it.
Inboxes in a run
Attach Fresh inbox per run to a step that needs an email address, such as a sign-up. The run creates a new address, and the agent uses it in the product and reads what arrives: it opens the link or types the code itself.
- Later steps that say "the same inbox" read the same address. Before saving, Autonomy suggests attaching the inbox to a step that waits for a code.
- An inbox closes when its run ends. Mail that arrives later is refused. The address stays reserved for your organization, so nobody else can get it.
- The run's Email previews tab shows each email as HTML, text and headers.
An address you only write in a step can be typed, but it can't be read. To read mail at an address you own, use your domain or a sign-in's inbox.
Codes and links
The agent reads received codes and links itself, and the run shows them in clear: in the email previews, in Step Actions and in the evidence. Only values you saved as secrets are masked.
While you record a test case in a hosted browser, you see the codes your session receives so you can finish a verification step. Other people see only that a code arrived, and codes are never stored in the recording or the test case.
Email verification
Choose how runs get through email verification in Organization → Integrations → Email verification:
| Mechanism | Use it when |
|---|---|
| Hosted inboxes (recommended) | Your app accepts any sign-up address. Codes and magic links both work, with no setup. |
| Test mode (static code) | Your app only accepts approved domains, and its test users get a fixed code. Codes only. |
| Your domain | Your app only accepts your domain, and you need magic links or real delivery. |
Test mode
Many auth providers let test addresses use a fixed verification code instead of a real email, such as Clerk's +clerk_test addresses with the code 424242. In test mode, Autonomy fills in that code and no email is sent.
- Address template: such as
qa+{token}@yourcompany.com.{token}becomes a random value per run, so parallel sign-ups never collide. - Test addresses: fixed accounts your sign-ins use.
- Static code: the code your backend accepts for them. It's stored write-only.
Test mode gives a code, not a link. Journeys that verify with a magic link need hosted inboxes or your domain.
Your domain
Receive real email on a subdomain you own, such as qa.yourcompany.com. Runs create addresses like r-a1b2c3d4@qa.yourcompany.com.
- Add a dedicated subdomain in Email verification.
- Prove ownership: add the TXT record shown, then click Verify.
- Forward the mail: set a catch-all forward for the subdomain to your organization's ingest address, shown in the settings. Cloudflare Email Routing, Google Workspace routing and Microsoft 365 transport rules all work.
- Activate: send any email to
test@qa.yourcompany.com. The first forwarded email turns forwarding on.
If your mail provider sends a forwarding-confirmation email to the ingest address, its link appears in the settings for owners and admins only.
Until forwarding is active, runs that need an inbox on your domain can't get one. Autonomy doesn't fall back to its own addresses, because your app would refuse them.
Inboxes of a project
The Email inboxes tab on a project's Sign-ins page lists its inboxes: Autonomy addresses, addresses on your domain, and inboxes kept from a run. Sign-ins use them for emailed codes and magic links. Owners, admins and the person who set an inbox up can read its latest messages.
Phone numbers
When a step asks for a phone number, the agent uses a made-up number in the format the field expects. Most journeys only need a number that looks right.
When the app needs to text the number, such as when it asks for an SMS code, the agent goes back, rents a real number, switches the app's country picker to that number's country, and enters it again. The step says whether it used a made-up or a rented number. Attaching Test phone number to a step tells the agent the step needs a phone; it follows the same rule.
- A rented number is listed under the run's created resources, and goes back when the run ends.
- An account that signed in with a rented number can't be kept as a saved sign-in.
- Some senders, such as banks, Google and WhatsApp, refuse virtual numbers. Delivery to them isn't guaranteed.
Phone numbers of a project
The Phone numbers tab on a project's Sign-ins page lists the numbers its sign-ins use. For sign-ins that receive SMS codes, the recommended option is a test number with a static code: your auth provider's test number (such as Firebase's fictional numbers or Supabase's test OTP) and the fixed code it accepts. Set it up in Organization → Integrations → Phone verification.
Billing
Each email a run's inbox receives costs $0.05, and each verified SMS delivery $0.35. See Billing.
Troubleshooting
The code never arrives
Check that the product sends to the address the run created, not one from an earlier run. Open the run's Email previews: if the email is there, the step's Step Actions show what the agent did with it. If it isn't, the product didn't send it, or your domain isn't forwarding yet.
The app refuses the inbox's domain
Your app restricts sign-up domains. Use test mode, or receive mail on your domain.
Didn’t find it?