**Management -> Waitlist**

Everyone who asked to hear when you go live, and the discount code they were
given. Signups arrive through the [waitlist API](/docs/api/waitlist/signups) from
your own marketing site, so the list fills up before the platform is public.

## The overview

Each row is one email address. The counters at the top break the list down by
status:

| Status       | Meaning                                                    |
| ------------ | ---------------------------------------------------------- |
| Waiting      | On the list, has not heard from you since the confirmation |
| Notified     | Your launch announcement has gone out to them              |
| Signed up    | They created an account with this address                  |
| Unsubscribed | They asked to be taken off                                 |

**Export CSV** downloads exactly what is on screen, filters included, so a search
on one campaign exports only that campaign.

Two actions sit on every row that is still subscribed: resend the confirmation,
and remove them from the list. Removing keeps the row, marked unsubscribed. That
is deliberate: deleting it would let the same address sign up again for a second
discount code, and would lose the fact that they asked not to be contacted.

## Settings

**Configuration -> Waitlist settings** decides what happens the moment somebody
leaves their email address. It is its own screen in the sidebar, and the waitlist
overview links to it as well.

### Collecting signups

While this is off, the API refuses new signups with `waitlist_disabled`. Everyone
already on the list stays on it. This is the switch to flip once you have
launched and the waitlist has served its purpose.

### Confirmation email

Sent immediately after a signup. Switch it off and people are added silently,
which only makes sense if you are collecting addresses for something you will
send yourself later.

The wording lives under **Email templates**, as two separate templates: one for
when there is a code and one for when there is not. You edit whichever applies to
your setup.

### Discount code

Three choices:

**No code.** Only the confirmation.

**One shared code.** Pick one of your existing coupons. Everybody gets that same
code, and you keep managing its discount, usage limit and expiry under
**Coupons** like any other. Good when you want a simple, quotable "use LAUNCH10".

**A personal code.** Every signup gets their own coupon, minted the second they
sign up. You set the discount, how long it stays valid, and an optional prefix so
the codes read as `LAUNCH-K4M9XR2P`. Each one works once, and it locks to the
person who signed up as soon as they create an account with the same email
address. Good when you do not want the code passed around.

:::note An unfinished setup does not turn people away
If you switch on a personal code but leave the discount empty, signups still
succeed and simply carry no code. Someone who left their email address should not
get an error because a settings screen was half filled in.
:::

## Permissions

| Permission               | What it allows                             |
| ------------------------ | ------------------------------------------ |
| View Waitlist            | See and export the list                    |
| Manage Waitlist          | Resend confirmations, remove people        |
| Manage Waitlist Settings | Change the signup behaviour and the reward |

## Connecting your website

Create a key under [API keys](/docs/platform/admin/api-keys) with the
`waitlist:write` scope and post to
[`POST /v1/waitlist/signups`](/docs/api/waitlist/create) from your server, never
from the browser. The response carries the discount code, so your page can show
it right away instead of making people wait for the email.