# Who can sign up

Let in only the addresses and domains you list, block others outright, or sign people up from a waitlist you approve.

[Closing public sign-up](/authentication/overview#closing-public-sign-up) is a yes or no for strangers. Sign-up access is the finer control: an allowlist of addresses and domains, a blocklist, and a waitlist mode where only the people you approve can create an account. Set it under **User Management → Access → Authentication → Sign-up**, in the **Who may sign up** card.

Step by step, with screenshots: [Set up who can sign up](/sign-in-setup/sign-up-access).

| Mode           | Who may sign up                                             |
| -------------- | ----------------------------------------------------------- |
| Anyone         | Everyone except the blocklist. The default                  |
| Allowlist only | Only the addresses and domains on the allowlist             |
| Waitlist       | People whose waitlist entry you approved, and the allowlist |

The blocklist applies in every mode. Existing accounts are never affected: these rules decide who may create an account, never who may sign in.

## Entries

Each list holds addresses (`ada@example.com`) and domains (`@example.com`). A domain covers its subdomains too, so `@example.com` also matches `ada@mail.example.com`. A bare `example.com` is read as `@example.com`. Entries are lower-cased and duplicates dropped when you save; an entry that is neither an address nor a domain is refused, naming it.

A list holds at most 1,000 entries. For more than that, list domains rather than people.

The lists are private. They are kept apart from your public auth config and never sent to the sign-in page, and a blocklisted address and one missing from the allowlist get the same sentence, "Sign-up isn't available for this address." Trying addresses one by one tells nobody what either list holds.

## How a sign-up is decided

In this order, at every door that creates an account: the register form, an email code, a social provider's first sign-in, phone and wallet sign-up, and a guest creating an account.

1. **The blocklist** refuses, even with a workspace invitation. An admin may have sent the invitation before the address was blocked.
2. **A live invitation** to that address lets the person in. The allowlist and the waitlist do not stand in its way.
3. **Closed public sign-up** refuses everyone else, as it always has.
4. **The mode** decides the rest. Anyone lets them in. Allowlist only lets in listed addresses. Waitlist lets in listed addresses and approved waitlist entries.

| Refusal                   | Sentence                                                                                            |
| ------------------------- | --------------------------------------------------------------------------------------------------- |
| `403` `signup_restricted` | "Sign-up isn't available for this address." The blocklist, or a miss on the allowlist               |
| `403` `waitlist_required` | "Join the waitlist, and you can sign up once you're approved." Waitlist mode, and no approved entry |

A social sign-in that is refused comes back to your page with the same `reason`, as [any refused social sign-in](/authentication/social-providers#when-a-sign-in-is-refused) does.

## The waitlist

Waitlist mode uses the waitlist you may already have. Choosing it turns the waitlist page on, and leaving it turns the page off.

- **People join** from the hosted register page, which leads with joining the waitlist and keeps the form for anyone already approved. A blocklisted address that joins is thanked and not stored.
- **You approve** entries on the console's **Beta users** page, under **User Management → Users**. An approved address can then sign up, with any method your client offers.
- **The allowlist** still goes straight in, so your team does not have to queue behind everyone else.

## Guests

[Guest users](/authentication/guests) have no address, so no list can name them. "Continue as guest" works only while public sign-up is open and the mode is Anyone; in the other modes the sign-in page does not show it.

## Saving it over the API

`GET /api/auth/signup-access` reads the setting, and `PUT` saves it:

```bash
curl -X PUT https://api.console.buildbase.app/api/auth/signup-access \
  -H "Authorization: Bearer $BUILDBASE_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"mode": "allowlist", "allow": ["@example.com", "ada@example.org"], "block": []}'
```

`mode` is `open`, `allowlist` or `waitlist`. A `PUT` replaces both lists, and a list left out is saved empty. A save applies at once. Both need a token whose role has the auth config permission, read for `GET` and update for `PUT`.

If the setting cannot be read at the moment someone signs up, that sign-up is treated as open rather than refused: a passing database or cache failure should not shut sign-up for everyone. An account that got through that way can be blocked from the user's page in the console.

## Next steps

- [Overview](/authentication/overview#closing-public-sign-up) - closing public sign-up altogether.
- [Bot Protection](/authentication/bot-protection) - keep scripts off the sign-up form, and refuse disposable addresses.
- [Guest users](/authentication/guests) - the one way in that needs sign-up open to anyone.