Inviting Users

Close a project to new sign-ups, then create accounts yourself. The person gets an email, chooses a password, and signs in with the role you gave them. For staff apps, invite-only betas, and anything where you decide who gets in.

Closing sign-ups

In the dashboard, open your project's auth settings and switch off Allow new sign-ups. Or through the API:

Close sign-ups

HTTP

PATCH /v1/projects/{project_id}/auth-settings
Authorization: Bearer <dashboard session>

{ "allow_signups": false }

With sign-ups closed, no one can create an account on their own — through any method: email and password, Google, Apple, or phone number. Each refuses with 403 and code signups_disabled. People who already have an account sign in exactly as before.

One switch per project

Sign-ups are open or closed for the whole project. If you need some people to register themselves while others are invited — customers open, staff invited — either invite both, or put them in separate projects. Deciding who may register is your application's rule, and belongs in your own function rather than a platform setting.

Inviting someone

In the dashboard, open Users and click Invite user. Or through the API:

Invite a user

HTTP

POST /v1/projects/{project_id}/users/invite
Authorization: Bearer <dashboard session>

{
  "email": "[email protected]",
  "full_name": "Ama Mensah",
  "claims": { "role": "officer", "region_id": "r3" }
}

full_name and claims are optional. An invite works whether sign-ups are open or closed — an administrator creating an account is not a sign-up. It needs project admin access, the same as editing a user's claims.

Claims come from you

Claims sent with the invite are applied before the person can sign in, and they are validated with the same rules as editing a user's claims in the dashboard. The person invited can't choose or change their own role. If the claims are invalid, nothing is created; the invite is refused and no email is sent.

What the person receives

An email saying they've been invited to your project, with a link to choose a password. It uses your project's email branding, and the link lasts 7 days.

The link opens the same page as a password reset: your own, if you've set one up (see Password Reset), or a page Koolbase hosts. Choosing a password there also marks their email as verified — clicking a link sent to an inbox proves they own it — so they can sign in straight away, even if your project requires verified contacts.

From then on they're an ordinary user and sign in however you've built sign-in.

Sending it again

Emails get lost, filtered, or expire before they're opened. Invite the same address again and, as long as the account has never been used, a fresh link is sent. Once any link is used to choose a password, every other link for that account stops working, so an older email can't be used afterwards.

An invite is refused with 409 — an account with this email already exists — when the account has been activated, has ever signed in, or has been disabled. A disabled account stays disabled; inviting it again won't bring it back.

Responses

201 — the account exists and the email is on its way (or a fresh link was sent)
400 — the email address or the claims are invalid; nothing was created
403 — you don't have admin access to this project
409 — an activated or disabled account already uses this email

A 201 means sent, not delivered

The email is handed to the mail provider, which can still refuse to deliver it — most often to an address that bounced before. If someone says they never received it, check the address, then invite again.