Stable slugs for roles and resources

Permission models that only have opaque ids are hard to copy between environments and hard to put in tokens. Groups, roles, and resources now carry readable slugs that stay unique per environment, and the management API can return the caller's effective permissions.

This is the longer note behind the December 14 changelog entry.

How it works

Slugs are required, unique on (environment_id, slug) for:

• groups
• roles
• resources
• permissions and policies (same uniqueness pattern)

The console role and resource views show the slug and let you copy it. Copying roles between environments maps resource links by resource slug, so a missing source slug cannot be remapped silently.

Effective permissions for the caller are exposed on the directory/RBAC API:

• GET /v1/tenants/{tenantId}/environments/{environmentId}/me/permissions

That list is the permissions the authenticated subject holds, including roles inherited through groups. JWT claim documentation treats roles as the user's role slugs (direct plus inherited).

Set it up

In the console, open Users authorization (roles and resources):

1. Give each role and resource a stable slug (billing, invoices).
2. Copy slugs into app checks or claim mappings instead of raw ids.
3. Call GET …/me/permissions as that user to confirm the effective set.

Changing a slug later breaks anything that stored the old value. Prefer rename-only when nothing depends on it.

Trust boundaries

A slug is an identifier, not an authorization decision. Enforcement stays server-side (RBAC, ABAC, or FGA for the environment). /me/permissions describes the caller; it does not grant extra access.

Do not treat a copied slug as proof the destination environment has the same permission graph until you verify the mapping.

Try it

Create a role with slug member, assign it, and call /me/permissions. Model notes are in Roles & permissions. The original release note is in the changelog.