Account and credential

Authentication & roles

Every other route under /account and /auth is not on the SDK surface (dashboard-only: an API key → 404): signing in, password resets, the email confirmation, sessions, identities, referral.

GET /account/referral and /account/referral/stats are under the members.referralCode policy: a member has their own referral code while the organization's members.referralCode policy allows it (on by default; off → 403 policy_disabled); the organization always has one. A member's code is inert while the policy is off: signing up with it succeeds without a referral (no error), whether an organization (POST /organization/sign-up/confirm, POST /auth/oidc/organization, POST /organization) or a qbf.cash handle (POST /handles/claim/confirm, POST /auth/oidc/handle); referrals made earlier stay and keep earning. A qbf.cash handle sign-up (the same two routes) with an unknown code now proceeds without a referral too (it answered 500).

The account — GET /account, PATCH /account

• GET /account → 200 User (uuid, firstName, lastName, email, createdAt, updatedAt): with a session, the signed-in user, whatever space the session is in (a member's space an owner or admin switched to, a staff view: the staff member); with an API key, the member it acts for (On-Behalf-Of, or a member's own key), or the user who created an organization key. The organization, role and mode are the session's (Login.space, GET /account/spaces), not the user's.
• PATCH /account (the signed-in user's own account; an API key → 404): only the fields sent change; an absent field is unchanged. firstName, lastName (2 to 100 characters, name rule), password (8 to 72 characters of the allowed set) and email. None can be cleared: "" is refused like any invalid value (400 validation_failed on the field). email or password need a recent re-authentication (403 reauth_required); the names don't. A new password ends the user's other logins, and the account's address is told. A new email is only applied once confirmed from the new address: the response keeps the current one, and the new address gets a confirmation link or, if it already has an account, an email saying so (the same answer either way). Answers 200 User.
• One pending email change. A new email replaces the pending one, whatever the address: the earlier link stops working. A password reset or POST /auth/logout-all cancels it too, so a change asked for with a stolen session doesn't outlive the owner's recovery.
• Account changes are told. A new password, a password reset, an email change (to the previous address) and a sign-in provider linked or removed send an "account changed" email to the account's address, with a link to reset the password if it wasn't them. The email names the kind of change only.

Status-code summary

• 401 unauthenticated, invalid credentials, or a session whose login or membership is gone; staff_view_ended (a staff view's token once the view ended).
• 403 signing in to the other app's account (or, on qbf.cash, an account without a handle); no_organization: a session without an organization on a route that needs one; reauth_required / invalid_password (re-authentication); staff_view_read_only (the referral routes in a staff view).
• 404 a dashboard-only route with an API key; a space the session can't enter.
• 400 validation failure, invalid_confirmation_token. 409 an email confirmed after another account took it; last_sign_in_method; refresh_conflict. 204 removing an identity.