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-request only returns { sent: true }. Retrieve the code from the side channel: GET /api/lab/inbox?to=<email>&kind=otp
✓ The #otp-peek button 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-code with 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

Related Challenges

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.

Testing Tips

Automation hints

✓ The OTP is never in the request response — clicking #otp-request only returns { sent: true }. Retrieve the code from the side channel: GET /api/lab/inbox?to=<email>&kind=otp
✓ The #otp-peek button 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-code with 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

OTP Login (Mock Inbox)

What you will learn

OTP Login — Read the Mock Inbox

Step 1 — Request a Code

Step 2 — Peek the Inbox (Practice Aid)

Step 3 — Verify & Log In

Testing Tips

Timer

Need Help?

Related Challenges

iFrames

Shadow DOM

Drag & Drop

OTP Login (Mock Inbox)

What you will learn

OTP Login — Read the Mock Inbox

Step 1 — Request a Code

Step 2 — Peek the Inbox (Practice Aid)

Step 3 — Verify & Log In

Testing Tips

Timer

Need Help?

Related Challenges

iFrames

Shadow DOM

Drag & Drop