Who can sign up

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.

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 ([email protected]) and domains (@example.com). A domain covers its subdomains too, so @example.com also matches [email protected]. 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.

A social sign-in that is refused comes back to your page with the same reason, as any refused social sign-in 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 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:

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", "[email protected]"], "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 - closing public sign-up altogether.
• Bot Protection - keep scripts off the sign-up form, and refuse disposable addresses.
• Guest users - the one way in that needs sign-up open to anyone.