Skip to main content
POST /v1/tenants/{tenant_id}/permissions/subject-permission The Subject Permission List endpoint answers the question: “Which permissions can user:1 perform on repository:1?” Instead of checking individual permissions one at a time, this endpoint evaluates all permissions defined in your schema for the entity type and returns a map of each permission name to its check result (RESULT_ALLOWED or RESULT_DENIED).
Use this endpoint to build permission-aware UIs — for example, deciding which buttons to show or which actions to enable based on the current user’s access to a specific resource.

​
Path Parameters

​
tenant_id
string
required
The tenant identifier. Use t1 for single-tenant deployments. Must match ^([a-zA-Z0-9_\-@\.:+]{1,128}|\*)$.

​
Request Body

​
metadata
object
required
​
entity
object
required
The entity to evaluate permissions against.
​
subject
object
required
The subject to evaluate permissions for.
​
context
object
Optional contextual data for ABAC evaluation. See Contextual Tuples.

​
Response

​
results
map[string, CheckResult]
A map of permission names to their check result for the given subject on the given entity.Possible values for each entry:
  • RESULT_ALLOWED — the subject has this permission
  • RESULT_DENIED — the subject does not have this permission

​
Example

curl --location --request POST 'localhost:3476/v1/tenants/{tenant_id}/permissions/subject-permission' \
--header 'Content-Type: application/json' \
--data-raw '{
  "metadata": {
    "snap_token": "",
    "schema_version": "",
    "only_permission": true,
    "depth": 20
  },
  "entity": {
    "type": "repository",
    "id": "1"
  },
  "subject": {
    "type": "user",
    "id": "1",
    "relation": ""
  }
}'

​
Response

{
  "results": {
    "push": "RESULT_ALLOWED",
    "read": "RESULT_ALLOWED",
    "delete": "RESULT_DENIED",
    "create_issue": "RESULT_ALLOWED"
  }
}

​
Use cases

  • UI permission gates — Determine which buttons, menu items, or actions to display for the current user on a given resource.
  • Audit views — Show an administrator all permissions a specific user has on an entity.
  • Batch pre-computation — Resolve all permissions for a resource upfront instead of checking each individually at render time.
only_permission: true filters out raw relation entries (e.g. owner, viewer) and returns only computed permission definitions. Set to false (the default) to include both.

Build docs developers (and LLMs) love

Get started for freeTalk to us