Skip to main content

Groups API

Use the Permit.io Groups API to give a set of users the same access in one call: assign a role to a group, and every member of the group derives that role. This page is for developers who manage relationship-based access control (ReBAC) groups through the API. To manage groups in the Permit dashboard instead, see Groups UI.

How groups work

A group is a resource instance of a group resource type, in one tenant. For example, the marketing instance of the teams resource type is a group. Groups build on ReBAC role derivation:

  • Group members. When you add a user to a group, Permit assigns the user the member role on the group instance. When you remove the user, Permit removes that role, and the user stops deriving the group's roles.
  • Group roles. When you assign a role on a resource instance to a group, Permit creates three objects: a relation between the group resource type and the resource type, a relationship between the group instance and the resource instance, and a role derivation from the group's member role to the assigned role. Every member of the group derives the assigned role on the resource instance, including users you add later.
  • Group hierarchy. When you assign one group to another group, Permit links the two groups with a relationship and a derivation between their member roles. Group-to-group assignment works only between groups of the same resource type.

Example: a marketing team that edits a training video

The marketing team must edit the training_video instance of the social_media resource type.

  1. Create a group with the instance key marketing and the resource type teams.
  2. Assign the editor role on social_media:training_video to the marketing group.
  3. Add the marketing users to the group.

Every user in the marketing group, including users you add later, derives the editor role on social_media:training_video. Give a user group access to a resource instance sets up this example step by step.

Prerequisites

  • An environment API key. See Get your API key.
  • The keys or IDs of your project and environment. See Get the project and environment.
  • A tenant for the group, the resource instances, and the users. A group, the resource instances it gets roles on, and its users must all use the same tenant.
  • Familiarity with ReBAC in Permit.

Groups API endpoints

All paths start with https://api.permit.io/v2/schema/{proj_id}/{env_id}.

TaskMethod and pathNotes
Create a groupPOST /groups
List groupsGET /groups/directUse instead of the deprecated GET /groups
Get a groupGET /groups/direct/{group_instance_key}Use instead of the deprecated GET /groups/{group_instance_key}
Delete a groupDELETE /groups/{group_instance_key}
Assign a role to a groupPOST /groups/{group_instance_key}/roles
Remove a role from a groupDELETE /groups/{group_instance_key}/roles
List the roles of a groupGET /groups/{group_instance_key}/rolesEarly access
Add a user to a groupPUT /groups/{group_instance_key}/users/{user_id}
Remove a user from a groupDELETE /groups/{group_instance_key}/users/{user_id}
List the users of a groupGET /groups/{group_instance_key}/usersEarly access
Assign a group to a groupPUT /groups/{group_instance_key}/assign_group
Remove a group from a groupDELETE /groups/{group_instance_key}/assign_group
List child groupsGET /groups/{group_instance_key}/childrenEarly access
List parent groupsGET /groups/{group_instance_key}/parentsEarly access

group_instance_key in a path has the format resource_type:instance, for example teams:marketing. The API reference marks the GET /groups and GET /groups/{group_instance_key} endpoints as deprecated. Use the /groups/direct endpoints for new code.

Give a user group access to a resource instance

This procedure sets up the marketing team example: members of the marketing group get the editor role on the training_video instance of social_media.

In every command, replace API_SECRET_KEY with your environment API key, and {proj_id} and {env_id} with your project and environment keys or IDs. The samples use the tenant default. Use one tenant key of your own in every call.

1. Create the group

Send a POST request with the group instance key, the resource type key, and the tenant. If you omit group_resource_type_key, the group's resource type is group.

curl 'https://api.permit.io/v2/schema/{proj_id}/{env_id}/groups' \
-H 'authorization: Bearer API_SECRET_KEY' \
-H 'Content-Type: application/json' \
--data-raw '{"group_instance_key": "marketing", "group_resource_type_key": "teams", "group_tenant": "default"}'

2. Create the resource and resource instance

Create the social_media resource with the actions the group's members need. A resource with no actions grants nothing, so a later check against it always returns false:

curl 'https://api.permit.io/v2/schema/{proj_id}/{env_id}/resources' \
-H 'authorization: Bearer API_SECRET_KEY' \
-H 'Content-Type: application/json' \
--data-raw '{"key": "social_media", "name": "social media", "actions": {"view": {"name": "view"}, "edit": {"name": "edit"}}}'

Create the training_video resource instance. Resource instances are facts objects, so the v2 path is /v2/facts/{proj_id}/{env_id}/resource_instances:

curl 'https://api.permit.io/v2/facts/{proj_id}/{env_id}/resource_instances' \
-H 'authorization: Bearer API_SECRET_KEY' \
-H 'Content-Type: application/json' \
--data-raw '{"key": "training_video", "tenant": "default", "resource":"social_media"}'

3. Create the editor role

The role you assign to a group must be a role of the target resource type. permissions takes the action keys the role grants on that resource type, so the editor role below grants view and edit on any social_media instance. A role created without permissions grants nothing. For the resource role endpoint, see ReBAC API calls.

curl 'https://api.permit.io/v2/schema/{proj_id}/{env_id}/resources/social_media/roles' \
-H 'authorization: Bearer API_SECRET_KEY' \
-H 'Content-Type: application/json' \
--data-raw '{"key": "editor", "name": "editor", "permissions": ["view", "edit"]}'

4. Assign the editor role to the group

Send a POST request to /groups/{group_instance_key}/roles with the resource type, the resource instance, the role, and the tenant. All four fields are required. The group instance key in the path uses the type:instance format, here teams:marketing.

curl 'https://api.permit.io/v2/schema/{proj_id}/{env_id}/groups/teams:marketing/roles' \
-H 'authorization: Bearer API_SECRET_KEY' \
-H 'Content-Type: application/json' \
--data-raw '{"resource": "social_media", "resource_instance": "training_video", "role": "editor", "tenant": "default"}'

5. Add users to the group

Send a PUT request for each user, with the tenant in the body. In the path, the group instance key is teams:marketing and {user_id} is the user key or ID.

curl -X PUT \
'https://api.permit.io/v2/schema/{proj_id}/{env_id}/groups/teams:marketing/users/{user_id}' \
-H 'authorization: Bearer API_SECRET_KEY' \
-H 'Content-Type: application/json' \
--data-raw '{"tenant": "default"}'

What Permit creates when you assign a role to a group

After step 4, Permit creates these objects:

  • A role derivation from the member role on teams to the editor role on social_media.
  • A relation between the teams resource type and the social_media resource type.
  • A relationship between the teams:marketing instance and the social_media:training_video instance.

Every user with the member role on teams:marketing derives the editor role on social_media:training_video, including users you add to the group later.

6. Verify the group setup

List the roles of the group. The response includes the editor role on social_media:training_video.

curl -X GET \
'https://api.permit.io/v2/schema/{proj_id}/{env_id}/groups/teams:marketing/roles' \
-H 'authorization: Bearer API_SECRET_KEY'

List the users of the group. The response includes the users you added in step 5.

curl -X GET \
'https://api.permit.io/v2/schema/{proj_id}/{env_id}/groups/teams:marketing/users' \
-H 'authorization: Bearer API_SECRET_KEY'

Then run permit.check() for a user you added in step 5, the edit action, and the social_media:training_video instance, in the default tenant. The check returns true, because the user's member role on teams:marketing derives the editor role on that instance, and editor grants edit. A check for an action the editor role doesn't grant returns false. See Check permissions.

Assign a group to another group

Assign one group to another group to build a group hierarchy, for example a support team inside an organization. In this example, the support group and the org1 group both use the default group resource type, and org1 is assigned to support.

Limitation: groups must share a resource type

You can assign a group only to a group of the same resource type. For example, you can assign group:org1 to group:support, but not to teams:marketing.

1. Create the two groups

Create the support group:

curl 'https://api.permit.io/v2/schema/{proj_id}/{env_id}/groups' \
-H 'authorization: Bearer API_SECRET_KEY' \
-H 'Content-Type: application/json' \
--data-raw '{"group_instance_key": "support", "group_tenant": "default"}'

Create the org1 group:

curl 'https://api.permit.io/v2/schema/{proj_id}/{env_id}/groups' \
-H 'authorization: Bearer API_SECRET_KEY' \
-H 'Content-Type: application/json' \
--data-raw '{"group_instance_key": "org1", "group_tenant": "default"}'

2. Assign one group to the other

Send a PUT request to /groups/{group_instance_key}/assign_group. The body holds the key of the other group in the type:instance format, here group:org1.

curl -X PUT \
'https://api.permit.io/v2/schema/{proj_id}/{env_id}/groups/group:support/assign_group' \
-H 'authorization: Bearer API_SECRET_KEY' \
-H 'Content-Type: application/json' \
--data-raw '{"group_instance_key": "group:org1"}'

When you assign org1 to support, Permit creates:

  • A role derivation from the member role on group to the member role on group.
  • A relation from the group resource type to itself.
  • A relationship between the group:support instance and the group:org1 instance.

3. Verify the group hierarchy

List the child groups of a group:

curl -X GET \
'https://api.permit.io/v2/schema/{proj_id}/{env_id}/groups/group:support/children' \
-H 'authorization: Bearer API_SECRET_KEY'

List the parent groups of a group:

curl -X GET \
'https://api.permit.io/v2/schema/{proj_id}/{env_id}/groups/group:org1/parents' \
-H 'authorization: Bearer API_SECRET_KEY'

The child list of one group includes the other group, and the parent list of the other group includes the first group.

List and get groups

List all groups

List the groups in an environment as a flat, paginated list, without their hierarchy:

curl -X GET \
'https://api.permit.io/v2/schema/{proj_id}/{env_id}/groups/direct' \
-H 'authorization: Bearer API_SECRET_KEY'

To filter the list, add the tenant, resource, or search query parameter. Use page and per_page (up to 100) to page through results.

Get a specific group

Get one group by its group instance key, for example teams:marketing:

curl -X GET \
'https://api.permit.io/v2/schema/{proj_id}/{env_id}/groups/direct/teams:marketing' \
-H 'authorization: Bearer API_SECRET_KEY'

The response holds the group resource type key, the group instance key, the tenant, and the group ID.

API reference

For request and response schemas of every Groups endpoint, see the Groups section of the Permit API reference.