Loading challenge...
OTP Login (Mock Inbox)
Retrieve a one-time code from a side-channel inbox and verify it — the API+UI hybrid dance
What you will learn
- Combine UI actions with direct API reads to retrieve an out-of-band OTP side channel
- Poll an endpoint until a value is delivered rather than relying on a fixed sleep
- Drive a passwordless login flow end-to-end and assert the session-setting success state
OTP Login — Read the Mock Inbox
The one-time code is never returned by the request endpoint — you must fetch it from a side channel (the inbox), then submit it to log in
Request a code for an email, then retrieve the current 6-digit code from GET /api/lab/inbox — the side channel a real test reads programmatically. Submit it to set the session cookie.
This is the classic API + UI hybrid dance: the UI triggers the request, but the secret travels through a separate channel that your automation must poll and read.
Step 1 — Request a Code
Send the OTP to an email address
Step 2 — Peek the Inbox (Practice Aid)
In a real test you'd read this channel programmatically — here a button reveals it
Step 3 — Verify & Log In
Submit the 6-digit code to set the session
Testing Tips
Automation hints
- ✓ The OTP is never in the request response — clicking
#otp-requestonly returns{ sent: true }. Retrieve the code from the side channel:GET /api/lab/inbox?to=<email>&kind=otp - ✓ The
#otp-peekbutton is a learning aid that shows the code in#otp-inbox-code; in a real test you read that endpoint programmatically and skip the UI button entirely - ✓ Poll the inbox until the code is delivered rather than a fixed
sleep— assert the code is present, then proceed (delivery is eventually consistent) - ✓ Fill
#otp-codewith the fetched code and click#otp-verify; success reveals#otp-success, a wrong/expired code reveals#otp-error(401 from the server) - ✓ This is the API + UI hybrid dance — drive the UI, but read the secret over a separate HTTP channel; the session cookie is set same-origin so it flows automatically
