Signing in when you belong to no organization

Public, throttled per IP. Submit EXACTLY ONE of email / phone — the identifier the user started with is all they have to remember — and the resolver answers { state, method, maskedDestination, nextStep, canResend, expiresAt } with the step to render. It never returns a credential: no token, no code, no password reset. The state is DERIVED from facts that already exist (status, password hash, *_verified_at, live tokens, memberships), with precedence: a finished account outranks a stale token, a pending invitation outranks a half-finished self sign-up, an active membership outranks an invited one. SEVEN states: not_started (no user with that identifier → the sign-up form) · awaiting_phone_otp (phone, no user, a live register OTP → the OTP screen with resend) · awaiting_password (user, phone verified, no password, no membership → “finish setting up — choose a password”; the phone is re-challenged before a registrationToken is re-issued) · awaiting_email_code (email unverified — reported even when the code has LAPSED, with canResend: true) · awaiting_invitation (a membership is invited → “you have a pending invitation”) · awaiting_tenant (user active, everything proven, NO membership of any kind → “create your organization”, §136 / scenario 15 — its nextStep is still POST /v1/auth/login, because resume cannot mint the bootstrapToken and login answers noOrganization with it; this used to report complete and send the user to a login that answered 403) · complete (active, ≥1 active membership → “log in”; also a user whose only membership is SUSPENDED — login then reports the real reason). Deliberately an enumeration oracle (the same posture register's 409 email_already_registered already takes); CAPTCHA/bot defence remains a production prerequisite for this surface.

Public, unauthenticated login. No Authorization header; send only the JSON body below. Throttled per credential/IP; response is no-store. A 200 is a BODY TO READ, not a status to trust — five shapes share it: tokens, a challenge chain (scenario 11–13), the legacy MFA challenge, { noOrganization, bootstrapToken } when the credential is good but you belong nowhere (scenario 15 — paste the token into POST /v1/auth/organizations/bootstrap), and { invitationPending, acceptToken, invitations[] } when your only seats are unaccepted invitations (scenario 52 — paste the token into POST /v1/auth/invitations/accept). The last two mint nothing session-shaped. Which one you get is NOT checkable beforehand (there is no pre-login MFA-status endpoint, by anti-enumeration design). Before the credential is examined at all, the active LOGIN policy is checked: if the channel this attempt uses is off, the answer is 403 login_method_disabled for a right and a wrong password alike (which discloses nothing — GET /v1/auth/login-policy publishes the same fact unauthenticated). Read that policy first in scenario 7.

The way out for a caller who belongs to NO organization (§136) — typically a member removed from their only one, who can authenticate but has nowhere for a session to live. PUBLIC BY NECESSITY: the caller has no session, which is the defect; the bootstrapToken authenticates them and the subject comes from the verified token, never the body. No step-up. 200 with the ordinary token shape plus the refresh_token cookie — the session is issued INTO the organization just founded (named explicitly, so a concurrent invitation acceptance cannot land you elsewhere), you are its admin, and amr is [bootstrap]. Capped exactly as POST /v1/me/organizations is — one live founded organization per identity → 409 organization_already_owned, which also stops the token being replayed into a second organization inside its TTL (there is no single-use marker). Once you belong somewhere, login answers normally and this answers 409. NO DEVICE TRUST: the body takes no trustDevice (.strict() refuses one); the next ordinary login earns it. 429 over the per-user organization-creation cap. Walk-through: scenario 15.