Overview
How to create users in a tenant — three paths, when to use each, and the credentials each one needs.
User creation in Febasi Auth goes through a single endpoint, POST /api/v1/register. What differs across integrations is who calls it and with what credential. There are three legitimate paths; this overview is the map.
The endpoint is protected by dual auth and requires the users:create scope on whichever credential reaches it. There is no public, unauthenticated signup.
The three paths
| Path | Caller | Best fit |
|---|---|---|
| Admin via Eved dashboard | The Users tab inside your Auth project in Eved | Onboarding the first user of a tenant or one-off admin actions, no code. |
| Admin via JWT (in-product) | A tenant admin authenticated with a Bearer JWT, calling from their own app | Admin UIs that let an authenticated admin create other users in the same tenant. |
| Server-side proxy via Client Key | The tenant's backend, holding a ck_* Client Key with users:create and sending X-Tenant-Code | Public signup pages. The browser never sees the credential. |
All three end up calling the same route with the same body. The credential controls who can sign up where; the scope (users:create) controls what the credential can do.
What's in this topic
Registration flow
The request body, response shape, password policy, and the post-registration role-assignment step.
Summary
Cheat sheet: pick a path, copy the curl, watch for the four most common errors.
Related
- Getting started — quickstart that places registration in context.
- Onboarding — when the tenant itself doesn't exist yet.
- IP allowlist — pin the Client Key to your backend's egress for defense in depth.