Users, roles & groups
Every instance has its own identity realm — users, roles, groups, SSO providers and password policies are all per-instance. The admin panel manages the realm for you; you never need to touch the identity provider directly.
Users
Users lists the realm's accounts. Inviting a user creates the identity and links it into the instance database, where a matching database role is created automatically — that database role is what your grants and row-level security act on.
Roles
Roles come in two tiers:
- Platform roles — e.g.
admin(full instance control), feature roles such as data-model or release management. - App roles — each app gets
<slug>_accesswhen created (grants schema usage + navigation visibility), plus any roles you define for it.
Assign roles directly or through groups. Role assignments take effect on the user's next token refresh (minutes, not sessions).
Groups
Groups bundle role sets: put sales_access + crm_editor in a
Sales team group and assign the group. Groups can be app-scoped so app
managers can maintain their own team membership without platform admin
rights.
Programmatic management
Identity operations are exposed as database functions callable through the gated RPC — the platform's own admin UI uses exactly these:
# Create a user in the instance realm
curl -X POST -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
-d '{"p_realm": "nexp_acme", "p_email": "[email protected]", "p_first": "Dana"}' \
"$DATA_API/v1/acme/rpc/core/iam_create_user"
# Assign realm roles
curl -X POST -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
-d '{"p_realm": "nexp_acme", "p_id": "<user-id>", "p_roles": "[{\"name\": \"crm_editor\"}]"}' \
"$DATA_API/v1/acme/rpc/core/iam_assign_user_roles"