Skip to main content
GET
List permission recipients
Assigning a permission requires the UUID of a user or a permission group, and this is the endpoint that provides them. There is no separate public listing of workspace users or groups.

Only members are returned

The response contains active Members only. Owners and Admins are deliberately absent: they bypass data-level permissions entirely, so a grant to them would change nothing. If you are looking for a colleague and cannot find them here, check their role first.

Query parameters

Passing a resource excludes recipients who already have access there. This is picker semantics: the list answers “who can still be added”, never “who has access”. To read existing access, use List Permissions instead. Without a resource parameter you get every eligible member and group.
A resource id that does not exist, or that your API key cannot see, returns 400 rather than an empty list — so a typo fails loudly instead of looking like “nobody available”.

Response

By default the endpoint returns bare id lists:
Pass expand to get full objects instead, which is what you want when you need to match people by email:

Find a person by email, then grant

Authorizations

x-api-key
string
header
required

API Key authentication. Format: 'x-api-key: api_key'

Query Parameters

folder
string

Only recipients who can still be granted on this folder.

layer
string

Only recipients who can still be granted on this layer.

Match users by name, username or email, and groups by name or description.

table
string

Only recipients who can still be granted on this table.

volume
string

Only recipients who can still be granted on this volume.

Response

200 - application/json
groups
string<uuid>[]
required
users
string<uuid>[]
required