---
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.

## 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`` says whether the questionnaire was ever submitted, so the form stays dismissed across reloads without the client storing anything. False on the account-less answers (``verification_pending``), where no row exists to have collected it.
  - `status` 'verification_pending' | 'preparing' | 'ready' | 'failed' | 'waitlisted' | 'paused', required
  - `profile_collected` boolean

---

[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-service-production.skmtc.workers.dev/v1/apis/maia-analytics/maia-api/revisions/0c94a4b5a00e/schema)