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

This read creates nothing, mails nothing, and answers only about the
caller's own address, so it leaks nothing the account's existence has not
already committed to.

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. ``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', 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 exactly one thing, and this is the one statement of it that the rest of the codebase points at rather than restates: the workspace records ``WorkspaceOrigin.DIRECT_PAID`` rather than ``SELF_SERVE_DISCOVERY``, which is what routes the account to checkout. It exempts nothing. Signup is unconditional, so there is no admission for a buyer to be exempt from, and every abuse gate binds either way — a verified address, the rate limits and the disposable-domain block. It is therefore not a privilege worth stealing: everything it unlocks is reachable through the free door by anyone the paid door would admit.

## Changes

- **2026-09-23** `7720763f8bf1` — 2 info
  - removed the `paused` enum value from the `status` response property for the response status `200`
  - removed the `waitlisted` enum value from the `status` response property for the response status `200`
- **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/bb508e935174?raw)