Appearance
Signup flow
Reached from the email/password login page via the "Sign up" link, and ends with OTP verification. The registration call itself is brand-authenticated — the customer JWT only arrives once the OTP is exchanged at stage 4.
Play the flow
Registration end to end. Press Play: the phone follows the form, and the steps name the one call that creates the account and the second one that turns it into a session.
4:4713
batch
log in to your account or create one
more login options
skip for now
by continuing, you agree to our terms of use and privacy policy.
Space plays and pauses, ← and → step. Screens marked not designed yet are ones the documented flow requires but that have no design — they are drawn from the steps, not invented.
Stages
API calls by stage
| Stage | Action | API call | Auth |
|---|---|---|---|
| 1–2 | Form is filled in locally | No call. Nothing in the form needs server validation before submit | — |
| 3 | Tap Signup | POST /api/v1/mobile/register — email, password, firstName, lastName in payload; source/medium/device as query params | Brand |
| 4 | OTP popup appears | No call. register generates and sends the OTP itself and returns { message, userId, phoneNumber } — render the popup from that response | — |
| 4 | Resend the code | POST /api/v1/mobile/send-otp — resend only, never on the happy path | Brand |
| 4 | Submit the OTP | POST /api/v1/mobile/login with email + otp. This is what returns the customer JWT | Brand |
| 5 | First home page load | POST /api/v2/brand/mobile/loyalty/init — "call once after signup to create the loyalty profile" | Customer |
| 5 | Then the usual home page reads | Same set as login stage 5 | Customer |
What the form has that the API does not
Three fields on this screen have no counterpart in the register payload, so they are the client's business only — worth stating in the spec so nobody looks for a field to send:
- Re-enter password — the schema takes a single
password(min 8). Matching is a client-side check. - Agree to Terms & Conditions — not a field on
register. If acceptance has to be recorded, that needs a decision; nothing in the mobile API set stores it. - OTP verification is not a dedicated endpoint. There is no
verify-signup-otp:registersends the code, andloginwithotpboth authenticates and proves the address.
Path
Login Page → More login options → Email & Password Login Page → Sign up link → first name → last name → email → password → re-enter password → agree to Terms & Conditions → Signup button → OTP popup → Home Page
Open questions
- Passwords not matching: inline validation or popup? (Client-side either way — see above.)
- Signup button state — disabled until T&C is checked, or error on tap?
- Email already registered: no path defined. The API answers this as HTTP 200 with
success: falseand a message, like every other failure. - Calling
send-otpstraight afterregistersends a second code and can invalidate the first. Wire it to a "Resend" control only. - OTP wrong / expired: no path defined. Is there a resend, and a retry limit?
send-otpcan be called again; no retry-limit behaviour is documented. - Where is the OTP delivered — email or phone? No phone number is collected in the form, so presumably email.
registerdoes acceptphoneNumber+phone_prefixif the form ever grows a phone field, andsend-otptakes either identifier. - The form collects no
username, but the profile screen lets a user set one andGET /api/v1/user/mobile/available/usernamerequires a customer token — so a username can only be chosen after signup, never during it.