Set up a waitlist

A waitlist lets people ask for an account without creating one. You approve the row, then they get an invitation. Until you do, they are not a user and they have no session.

Use it when sign-up should exist as a request, not as access. For a closed customer, restricted mode is stricter: there is no public join form at all.

Turn it on

1. Open the console and select the environment.
2. Go to Authentication > Restrictions.
3. Set Sign-up mode to Waitlist.

You can also turn Waitlist mode on from Users > Settings. Either switch sends new sign-ups to the queue. Public mode and waitlist mode should not both be the story you tell users. Confirm the Restrictions mode after you save.

Email rules still apply. An allowlist, a blocklist, disposable-email blocking, and the subaddress limit reject a join before it becomes a row. See Access control.

Approve people

Open Users > Waitlist. The table shows Email, Status, Source, Joined at, and Invited at. Rows appear only while sign-up is in waitlist mode.

Approve an entry to create the user and send the invitation. Invitation expiry is the period under Authentication > Features (default 7 days). An approval that sits past that window needs a new invite.

USER_JOINED_WAITLIST fires when someone joins. You can forward it with events if another system should hear about the request. Approval is still a console action. The event is not the approval.

Stop the queue from being the attack

A waitlist without a challenge is a free inbox for scripts. They don't get a session, but they fill the table and your mail provider.

On Authentication > Add-ons, enable reCAPTCHA or Turnstile for the waitlist action. An invisible challenge is enough to start. The walkthrough is Prevent signup abuse and Bot protection.

Review the queue before you bulk-approve. A burst of similar addresses is the script, not demand.

Related