--- title: "Get Signup Status" method: GET path: "/api/v1/auth/signup/status" tags: ["auth"] --- # Get Signup Status `GET /api/v1/auth/signup/status` Where the caller's own self-serve setup stands. Deliberately NOT gated on the public signup toggle: an operator switching the surface off must not strand people mid-setup, and this read creates nothing, mails nothing, and answers only about the caller's own address — so keeping it alive leaks nothing the account's existence hasn't already committed to. The write paths stay behind the toggle. ``paused`` is derived from the live pause flag rather than stored, so a waitlisted person always sees the current admission posture. No account row exists until the verification link is redeemed, so a bare 404 there would tell a mid-verification return "you never signed up" while their link is still live — an outstanding link reports ``verification_pending`` instead, and only a truly unknown address 404s. ``intent`` comes from the account when there is one and from the live link when there is not, which is the only place it exists before redemption. The page resends the verification mail from this answer, so a ``verification_pending`` read that reported no intent would have a buyer resend themselves a free signup. ## Response `200` Successful Response - SetupStatusResponse — Where a self-serve setup stands, as the status page renders it. Exactly what the UI needs and nothing internal — no workflow ids, no failure reasons. ``paused`` is derived live from the operator pause flag at read time, never stored, so unpausing immediately changes what a returning waitlisted person sees. ``profile_collected`` is retained for questionnaire-era clients during the rolling-deploy compatibility window. The current client ignores it and enters as soon as setup is ready; MAIA-4460 removes the field after older clients can no longer submit the questionnaire. ``intent`` is what the account was admitted with, read from the account row. A buyer's tab can be closed and reopened — or the verification link redeemed on another device — so the status poll is where a returning client learns it is heading for checkout rather than the app. - `status` 'verification_pending' | 'preparing' | 'ready' | 'failed' | 'waitlisted' | 'paused', required - `profile_collected` boolean - `intent` 'free' | 'paid' — What a public signup is asking for. ``PAID`` is what a buyer arriving from the pricing page carries. It is not a funding fact — nothing is charged until checkout, and the workspace opens on the same joining grant a free signup gets — so it decides only two things, and this is the one statement of them that the rest of the codebase points at rather than restates: 1. None of the free Discovery experiment's controls bind. The seat cap, the waitlist and the operator pause are that experiment's budget, and a buyer is not in it: a paid account holds no seat, so admitting one spends nothing the cap was sized to protect. Its abuse gates still bind — a verified address, the rate limits and the disposable-domain block — because those protect MAIA, not the experiment. The work-email rule is the exception: it decides who the free experiment is offered to, and refusing a buyer for paying from a personal address is a lost sale. 2. The workspace records ``WorkspaceOrigin.DIRECT_PAID`` rather than ``SELF_SERVE_DISCOVERY``. It is not a privilege worth stealing: everything it unlocks is reachable through the free door by anyone the paid door would admit, except during the hours the free cohort is full or paused. ## Changes - **2026-09-19** `924eeadc29ad` — 1 info - added the optional property `intent` to the response with the `200` status - **2026-08-25** `b61a1454aad6` — 1 info - endpoint added [Change history](https://skmtc.dev/maia-analytics/apis/maia-api/changes/api/v1/auth/signup/status/get.md) --- [API](https://skmtc.dev/maia-analytics/apis/maia-api.md) · [All operations](https://skmtc.dev/maia-analytics/apis/maia-api/llms.txt) · [OpenAPI document](https://skmtc.dev/maia-analytics/apis/maia-api/revisions/8dc47faf0418?raw)