OpenFGA Relationship Queries API
The Relationship Queries API from OpenFGA — 6 operation(s) for relationship queries.
OpenAPI Specification
swagger: '2.0'
info:
title: OpenFGA Assertions Relationship Queries API
description: A high performance and flexible authorization/permission engine built for developers and inspired by Google Zanzibar.
version: 1.x
contact:
name: OpenFGA
url: https://openfga.dev
email: community@openfga.dev
license:
name: Apache-2.0
url: https://github.com/openfga/openfga/blob/main/LICENSE
schemes:
- https
consumes:
- application/json
produces:
- application/json
tags:
- name: Relationship Queries
paths:
/stores/{store_id}/batch-check:
post:
summary: Send a list of `check` operations in a single request
description: "The `BatchCheck` API functions nearly identically to `Check`, but instead of checking a single user-object relationship BatchCheck accepts a list of relationships to check and returns a map containing `BatchCheckItem` response for each check it received.\n\nAn associated `correlation_id` is required for each check in the batch. This ID is used to correlate a check to the appropriate response. It is a string consisting of only alphanumeric characters or hyphens with a maximum length of 36 characters. This `correlation_id` is used to map the result of each check to the item which was checked, so it must be unique for each item in the batch. We recommend using a UUID or ULID as the `correlation_id`, but you can use whatever unique identifier you need as long as it matches this regex pattern: `^[\\w\\d-]{1,36}$`\n\nNOTE: The maximum number of checks that can be passed in the `BatchCheck` API is configurable via the [OPENFGA_MAX_CHECKS_PER_BATCH_CHECK](https://openfga.dev/docs/getting-started/setup-openfga/configuration#OPENFGA_MAX_CHECKS_PER_BATCH_CHECK) environment variable. If `BatchCheck` is called using the SDK, the SDK can split the batch check requests for you.\n\nFor more details on how `Check` functions, see the docs for `/check`.\n\n### Examples\n#### A BatchCheckRequest\n```json\n{\n \"checks\": [\n {\n \"tuple_key\": {\n \"object\": \"document:2021-budget\"\n \"relation\": \"reader\",\n \"user\": \"user:anne\",\n },\n \"contextual_tuples\": {...}\n \"context\": {}\n \"correlation_id\": \"01JA8PM3QM7VBPGB8KMPK8SBD5\"\n },\n {\n \"tuple_key\": {\n \"object\": \"document:2021-budget\"\n \"relation\": \"reader\",\n \"user\": \"user:bob\",\n },\n \"contextual_tuples\": {...}\n \"context\": {}\n \"correlation_id\": \"01JA8PMM6A90NV5ET0F28CYSZQ\"\n }\n ]\n}\n```\n\nBelow is a possible response to the above request. Note that the result map's keys are the `correlation_id` values from the checked items in the request:\n```json\n{\n \"result\": {\n \"01JA8PMM6A90NV5ET0F28CYSZQ\": {\n \"allowed\": false, \n \"error\": {\"message\": \"\"} \n },\n \"01JA8PM3QM7VBPGB8KMPK8SBD5\": {\n \"allowed\": true, \n \"error\": {\"message\": \"\"} \n }\n}\n```\n"
operationId: BatchCheck
responses:
'200':
description: A successful response.
schema:
$ref: '#/definitions/BatchCheckResponse'
'400':
description: Request failed due to invalid input.
schema:
$ref: '#/definitions/ValidationErrorMessageResponse'
'401':
description: Not authenticated.
schema:
$ref: '#/definitions/UnauthenticatedResponse'
'403':
description: Forbidden.
schema:
$ref: '#/definitions/ForbiddenResponse'
'404':
description: Request failed due to incorrect path.
schema:
$ref: '#/definitions/PathUnknownErrorMessageResponse'
'409':
description: Request was aborted due a transaction conflict.
schema:
$ref: '#/definitions/AbortedMessageResponse'
'422':
description: Request timed out due to excessive request throttling.
schema:
$ref: '#/definitions/UnprocessableContentMessageResponse'
'500':
description: Request failed due to internal server error.
schema:
$ref: '#/definitions/InternalErrorMessageResponse'
parameters:
- name: store_id
in: path
required: true
type: string
- name: body
in: body
required: true
schema:
type: object
properties:
checks:
type: array
items:
type: object
$ref: '#/definitions/BatchCheckItem'
minItems: 1
authorization_model_id:
type: string
example: 01G5JAVJ41T49E9TT3SKVS7X1J
consistency:
$ref: '#/definitions/ConsistencyPreference'
required:
- checks
tags:
- Relationship Queries
/stores/{store_id}/check:
post:
summary: Check whether a user is authorized to access an object
description: "The Check API returns whether a given user has a relationship with a given object in a given store.\nThe `user` field of the request can be a specific target, such as `user:anne`, or a userset (set of users) such as `group:marketing#member` or a type-bound public access `user:*`.\nTo arrive at a result, the API uses: an authorization model, explicit tuples written through the Write API, contextual tuples present in the request, and implicit tuples that exist by virtue of applying set theory (such as `document:2021-budget#viewer@document:2021-budget#viewer`; the set of users who are viewers of `document:2021-budget` are the set of users who are the viewers of `document:2021-budget`).\nA `contextual_tuples` object may also be included in the body of the request. This object contains one field `tuple_keys`, which is an array of tuple keys. Each of these tuples may have an associated `condition`.\nYou may also provide an `authorization_model_id` in the body. This will be used to assert that the input `tuple_key` is valid for the model specified. If not specified, the assertion will be made against the latest authorization model ID. It is strongly recommended to specify authorization model id for better performance.\nYou may also provide a `context` object that will be used to evaluate the conditioned tuples in the system. It is strongly recommended to provide a value for all the input parameters of all the conditions, to ensure that all tuples be evaluated correctly.\nBy default, the Check API caches results for a short time to optimize performance. You may specify a value of `HIGHER_CONSISTENCY` for the optional `consistency` parameter in the body to inform the server that higher conisistency is preferred at the expense of increased latency. Consideration should be given to the increased latency if requesting higher consistency.\nThe response will return whether the relationship exists in the field `allowed`.\n\nSome exceptions apply, but in general, if a Check API responds with `{allowed: true}`, then you can expect the equivalent ListObjects query to return the object, and viceversa. \nFor example, if `Check(user:anne, reader, document:2021-budget)` responds with `{allowed: true}`, then `ListObjects(user:anne, reader, document)` may include `document:2021-budget` in the response.\n## Examples\n### Querying with contextual tuples\nIn order to check if user `user:anne` of type `user` has a `reader` relationship with object `document:2021-budget` given the following contextual tuple\n```json\n{\n \"user\": \"user:anne\",\n \"relation\": \"member\",\n \"object\": \"time_slot:office_hours\"\n}\n```\nthe Check API can be used with the following request body:\n```json\n{\n \"tuple_key\": {\n \"user\": \"user:anne\",\n \"relation\": \"reader\",\n \"object\": \"document:2021-budget\"\n },\n \"contextual_tuples\": {\n \"tuple_keys\": [\n {\n \"user\": \"user:anne\",\n \"relation\": \"member\",\n \"object\": \"time_slot:office_hours\"\n }\n ]\n },\n \"authorization_model_id\": \"01G50QVV17PECNVAHX1GG4Y5NC\"\n}\n```\n### Querying usersets\nSome Checks will always return `true`, even without any tuples. For example, for the following authorization model\n```python\nmodel\n schema 1.1\ntype user\ntype document\n relations\n define reader: [user]\n```\nthe following query\n```json\n{\n \"tuple_key\": {\n \"user\": \"document:2021-budget#reader\",\n \"relation\": \"reader\",\n \"object\": \"document:2021-budget\"\n }\n}\n```\nwill always return `{ \"allowed\": true }`. This is because usersets are self-defining: the userset `document:2021-budget#reader` will always have the `reader` relation with `document:2021-budget`.\n### Querying usersets with difference in the model\nA Check for a userset can yield results that must be treated carefully if the model involves difference. For example, for the following authorization model\n```python\nmodel\n schema 1.1\ntype user\ntype group\n relations\n define member: [user]\ntype document\n relations\n define blocked: [user]\n define reader: [group#member] but not blocked\n```\nthe following query\n```json\n{\n \"tuple_key\": {\n \"user\": \"group:finance#member\",\n \"relation\": \"reader\",\n \"object\": \"document:2021-budget\"\n },\n \"contextual_tuples\": {\n \"tuple_keys\": [\n {\n \"user\": \"user:anne\",\n \"relation\": \"member\",\n \"object\": \"group:finance\"\n },\n {\n \"user\": \"group:finance#member\",\n \"relation\": \"reader\",\n \"object\": \"document:2021-budget\"\n },\n {\n \"user\": \"user:anne\",\n \"relation\": \"blocked\",\n \"object\": \"document:2021-budget\"\n }\n ]\n },\n}\n```\nwill return `{ \"allowed\": true }`, even though a specific user of the userset `group:finance#member` does not have the `reader` relationship with the given object.\n### Requesting higher consistency\nBy default, the Check API caches results for a short time to optimize performance. You may request higher consistency to inform the server that higher consistency should be preferred at the expense of increased latency. Care should be taken when requesting higher consistency due to the increased latency.\n```json\n{\n \"tuple_key\": {\n \"user\": \"group:finance#member\",\n \"relation\": \"reader\",\n \"object\": \"document:2021-budget\"\n },\n \"consistency\": \"HIGHER_CONSISTENCY\"\n}\n```\n"
operationId: Check
responses:
'200':
description: A successful response.
schema:
$ref: '#/definitions/CheckResponse'
'400':
description: Request failed due to invalid input.
schema:
$ref: '#/definitions/ValidationErrorMessageResponse'
'401':
description: Not authenticated.
schema:
$ref: '#/definitions/UnauthenticatedResponse'
'403':
description: Forbidden.
schema:
$ref: '#/definitions/ForbiddenResponse'
'404':
description: Request failed due to incorrect path.
schema:
$ref: '#/definitions/PathUnknownErrorMessageResponse'
'409':
description: Request was aborted due a transaction conflict.
schema:
$ref: '#/definitions/AbortedMessageResponse'
'422':
description: Request timed out due to excessive request throttling.
schema:
$ref: '#/definitions/UnprocessableContentMessageResponse'
'500':
description: Request failed due to internal server error.
schema:
$ref: '#/definitions/InternalErrorMessageResponse'
parameters:
- name: store_id
in: path
required: true
type: string
- name: body
in: body
required: true
schema:
type: object
properties:
tuple_key:
$ref: '#/definitions/CheckRequestTupleKey'
contextual_tuples:
$ref: '#/definitions/ContextualTupleKeys'
authorization_model_id:
type: string
example: 01G5JAVJ41T49E9TT3SKVS7X1J
trace:
type: boolean
example: false
description: Defaults to false. Making it true has performance implications.
readOnly: true
context:
type: object
description: 'Additional request context that will be used to evaluate any ABAC conditions encountered
in the query evaluation.'
consistency:
$ref: '#/definitions/ConsistencyPreference'
description: Controls the consistency preference for this request. Default value is UNSPECIFIED, which will have the same behavior as MINIMIZE_LATENCY.
required:
- tuple_key
tags:
- Relationship Queries
/stores/{store_id}/expand:
post:
summary: Expand all relationships in userset tree format, and following userset rewrite rules. Useful to reason about and debug a certain relationship
description: "The Expand API will return all users and usersets that have certain relationship with an object in a certain store.\nThis is different from the `/stores/{store_id}/read` API in that both users and computed usersets are returned.\nBody parameters `tuple_key.object` and `tuple_key.relation` are all required.\nA `contextual_tuples` object may also be included in the body of the request. This object contains one field `tuple_keys`, which is an array of tuple keys. Each of these tuples may have an associated `condition`.\nThe response will return a tree whose leaves are the specific users and usersets. Union, intersection and difference operator are located in the intermediate nodes.\n\n## Example\nTo expand all users that have the `reader` relationship with object `document:2021-budget`, use the Expand API with the following request body\n```json\n{\n \"tuple_key\": {\n \"object\": \"document:2021-budget\",\n \"relation\": \"reader\"\n },\n \"authorization_model_id\": \"01G50QVV17PECNVAHX1GG4Y5NC\"\n}\n```\nOpenFGA's response will be a userset tree of the users and usersets that have read access to the document.\n```json\n{\n \"tree\":{\n \"root\":{\n \"type\":\"document:2021-budget#reader\",\n \"union\":{\n \"nodes\":[\n {\n \"type\":\"document:2021-budget#reader\",\n \"leaf\":{\n \"users\":{\n \"users\":[\n \"user:bob\"\n ]\n }\n }\n },\n {\n \"type\":\"document:2021-budget#reader\",\n \"leaf\":{\n \"computed\":{\n \"userset\":\"document:2021-budget#writer\"\n }\n }\n }\n ]\n }\n }\n }\n}\n```\nThe caller can then call expand API for the `writer` relationship for the `document:2021-budget`.\n### Expand Request with Contextual Tuples\n\nGiven the model\n```python\nmodel\n schema 1.1\n\ntype user\n\ntype folder\n relations\n define owner: [user]\n\ntype document\n relations\n define parent: [folder]\n define viewer: [user] or writer\n define writer: [user] or owner from parent\n```\nand the initial tuples\n```json\n[{\n \"user\": \"user:bob\",\n \"relation\": \"owner\",\n \"object\": \"folder:1\"\n}]\n```\n\nTo expand all `writers` of `document:1` when `document:1` is put in `folder:1`, the first call could be\n\n```json\n{\n \"tuple_key\": {\n \"object\": \"document:1\",\n \"relation\": \"writer\"\n },\n \"contextual_tuples\": {\n \"tuple_keys\": [\n {\n \"user\": \"folder:1\",\n \"relation\": \"parent\",\n \"object\": \"document:1\"\n }\n ]\n }\n}\n```\nthis returns:\n```json\n{\n \"tree\": {\n \"root\": {\n \"name\": \"document:1#writer\",\n \"union\": {\n \"nodes\": [\n {\n \"name\": \"document:1#writer\",\n \"leaf\": {\n \"users\": {\n \"users\": []\n }\n }\n },\n {\n \"name\": \"document:1#writer\",\n \"leaf\": {\n \"tupleToUserset\": {\n \"tupleset\": \"document:1#parent\",\n \"computed\": [\n {\n \"userset\": \"folder:1#owner\"\n }\n ]\n }\n }\n }\n ]\n }\n }\n }\n}\n```\nThis tells us that the `owner` of `folder:1` may also be a writer. So our next call could be to find the `owners` of `folder:1`\n```json\n{\n \"tuple_key\": {\n \"object\": \"folder:1\",\n \"relation\": \"owner\"\n }\n}\n```\nwhich gives\n```json\n{\n \"tree\": {\n \"root\": {\n \"name\": \"folder:1#owner\",\n \"leaf\": {\n \"users\": {\n \"users\": [\n \"user:bob\"\n ]\n }\n }\n }\n }\n}\n```\n"
operationId: Expand
responses:
'200':
description: A successful response.
schema:
$ref: '#/definitions/ExpandResponse'
'400':
description: Request failed due to invalid input.
schema:
$ref: '#/definitions/ValidationErrorMessageResponse'
'401':
description: Not authenticated.
schema:
$ref: '#/definitions/UnauthenticatedResponse'
'403':
description: Forbidden.
schema:
$ref: '#/definitions/ForbiddenResponse'
'404':
description: Request failed due to incorrect path.
schema:
$ref: '#/definitions/PathUnknownErrorMessageResponse'
'409':
description: Request was aborted due a transaction conflict.
schema:
$ref: '#/definitions/AbortedMessageResponse'
'422':
description: Request timed out due to excessive request throttling.
schema:
$ref: '#/definitions/UnprocessableContentMessageResponse'
'500':
description: Request failed due to internal server error.
schema:
$ref: '#/definitions/InternalErrorMessageResponse'
parameters:
- name: store_id
in: path
required: true
type: string
- name: body
in: body
required: true
schema:
type: object
properties:
tuple_key:
$ref: '#/definitions/ExpandRequestTupleKey'
authorization_model_id:
type: string
example: 01G5JAVJ41T49E9TT3SKVS7X1J
consistency:
$ref: '#/definitions/ConsistencyPreference'
description: Controls the consistency preference for this request. Default value is UNSPECIFIED, which will have the same behavior as MINIMIZE_LATENCY.
contextual_tuples:
$ref: '#/definitions/ContextualTupleKeys'
required:
- tuple_key
tags:
- Relationship Queries
/stores/{store_id}/list-objects:
post:
summary: List all objects of the given type that the user has a relation with
description: "The ListObjects API returns a list of all the objects of the given type that the user has a relation with.\n To arrive at a result, the API uses: an authorization model, explicit tuples written through the Write API, contextual tuples present in the request, and implicit tuples that exist by virtue of applying set theory (such as `document:2021-budget#viewer@document:2021-budget#viewer`; the set of users who are viewers of `document:2021-budget` are the set of users who are the viewers of `document:2021-budget`).\nAn `authorization_model_id` may be specified in the body. If it is not specified, the latest authorization model ID will be used. It is strongly recommended to specify authorization model id for better performance.\nYou may also specify `contextual_tuples` that will be treated as regular tuples. Each of these tuples may have an associated `condition`.\nYou may also provide a `context` object that will be used to evaluate the conditioned tuples in the system. It is strongly recommended to provide a value for all the input parameters of all the conditions, to ensure that all tuples be evaluated correctly.\nBy default, the Check API caches results for a short time to optimize performance. You may specify a value of `HIGHER_CONSISTENCY` for the optional `consistency` parameter in the body to inform the server that higher conisistency is preferred at the expense of increased latency. Consideration should be given to the increased latency if requesting higher consistency.\nThe response will contain the related objects in an array in the \"objects\" field of the response and they will be strings in the object format `<type>:<id>` (e.g. \"document:roadmap\").\nThe number of objects in the response array will be limited by the execution timeout specified in the flag OPENFGA_LIST_OBJECTS_DEADLINE and by the upper bound specified in the flag OPENFGA_LIST_OBJECTS_MAX_RESULTS, whichever is hit first.\nThe objects given will not be sorted, and therefore two identical calls can give a given different set of objects."
operationId: ListObjects
responses:
'200':
description: A successful response.
schema:
$ref: '#/definitions/ListObjectsResponse'
'400':
description: Request failed due to invalid input.
schema:
$ref: '#/definitions/ValidationErrorMessageResponse'
'401':
description: Not authenticated.
schema:
$ref: '#/definitions/UnauthenticatedResponse'
'403':
description: Forbidden.
schema:
$ref: '#/definitions/ForbiddenResponse'
'404':
description: Request failed due to incorrect path.
schema:
$ref: '#/definitions/PathUnknownErrorMessageResponse'
'409':
description: Request was aborted due a transaction conflict.
schema:
$ref: '#/definitions/AbortedMessageResponse'
'422':
description: Request timed out due to excessive request throttling.
schema:
$ref: '#/definitions/UnprocessableContentMessageResponse'
'500':
description: Request failed due to internal server error.
schema:
$ref: '#/definitions/InternalErrorMessageResponse'
parameters:
- name: store_id
in: path
required: true
type: string
- name: body
in: body
required: true
schema:
type: object
properties:
authorization_model_id:
type: string
example: 01G5JAVJ41T49E9TT3SKVS7X1J
type:
type: string
example: document
relation:
type: string
example: reader
user:
type: string
example: user:anne
maxLength: 512
minLength: 1
contextual_tuples:
$ref: '#/definitions/ContextualTupleKeys'
context:
type: object
description: 'Additional request context that will be used to evaluate any ABAC conditions encountered
in the query evaluation.'
consistency:
$ref: '#/definitions/ConsistencyPreference'
description: Controls the consistency preference for this request. Default value is UNSPECIFIED, which will have the same behavior as MINIMIZE_LATENCY.
required:
- type
- relation
- user
tags:
- Relationship Queries
/stores/{store_id}/list-users:
post:
summary: List the users matching the provided filter who have a certain relation to a particular type.
description: "The ListUsers API returns a list of all the users of a specific type that have a relation to a given object.\n To arrive at a result, the API uses: an authorization model, explicit tuples written through the Write API, contextual tuples present in the request, and implicit tuples that exist by virtue of applying set theory (such as `document:2021-budget#viewer@document:2021-budget#viewer`; the set of users who are viewers of `document:2021-budget` are the set of users who are the viewers of `document:2021-budget`).\nAn `authorization_model_id` may be specified in the body. If it is not specified, the latest authorization model ID will be used. It is strongly recommended to specify authorization model id for better performance.\nYou may also specify `contextual_tuples` that will be treated as regular tuples. Each of these tuples may have an associated `condition`.\nYou may also provide a `context` object that will be used to evaluate the conditioned tuples in the system. It is strongly recommended to provide a value for all the input parameters of all the conditions, to ensure that all tuples be evaluated correctly.\nThe response will contain the related users in an array in the \"users\" field of the response. These results may include specific objects, usersets \nor type-bound public access. Each of these types of results is encoded in its own type and not represented as a string.In cases where a type-bound public access result is returned (e.g. `user:*`), it cannot be inferred that all subjects\nof that type have a relation to the object; it is possible that negations exist and checks should still be queried\non individual subjects to ensure access to that document.The number of users in the response array will be limited by the execution timeout specified in the flag OPENFGA_LIST_USERS_DEADLINE and by the upper bound specified in the flag OPENFGA_LIST_USERS_MAX_RESULTS, whichever is hit first.\nThe returned users will not be sorted, and therefore two identical calls may yield different sets of users."
operationId: ListUsers
responses:
'200':
description: A successful response.
schema:
$ref: '#/definitions/ListUsersResponse'
'400':
description: Request failed due to invalid input.
schema:
$ref: '#/definitions/ValidationErrorMessageResponse'
'401':
description: Not authenticated.
schema:
$ref: '#/definitions/UnauthenticatedResponse'
'403':
description: Forbidden.
schema:
$ref: '#/definitions/ForbiddenResponse'
'404':
description: Request failed due to incorrect path.
schema:
$ref: '#/definitions/PathUnknownErrorMessageResponse'
'409':
description: Request was aborted due a transaction conflict.
schema:
$ref: '#/definitions/AbortedMessageResponse'
'422':
description: Request timed out due to excessive request throttling.
schema:
$ref: '#/definitions/UnprocessableContentMessageResponse'
'500':
description: Request failed due to internal server error.
schema:
$ref: '#/definitions/InternalErrorMessageResponse'
parameters:
- name: store_id
in: path
required: true
type: string
- name: body
in: body
required: true
schema:
type: object
properties:
authorization_model_id:
type: string
example: 01G5JAVJ41T49E9TT3SKVS7X1J
object:
$ref: '#/definitions/Object'
example: document:example
relation:
type: string
example: reader
user_filters:
type: array
example:
- type: user
- type: group
relation: member
items:
type: object
$ref: '#/definitions/UserTypeFilter'
description: The type of results returned. Only accepts exactly one value.
maxItems: 1
minItems: 1
contextual_tuples:
type: array
items:
type: object
$ref: '#/definitions/TupleKey'
maxItems: 100
context:
type: object
description: 'Additional request context that will be used to evaluate any ABAC conditions encountered
in the query evaluation.'
consistency:
$ref: '#/definitions/ConsistencyPreference'
description: Controls the consistency preference for this request. Default value is UNSPECIFIED, which will have the same behavior as MINIMIZE_LATENCY.
required:
- object
- relation
- user_filters
tags:
- Relationship Queries
/stores/{store_id}/streamed-list-objects:
post:
summary: Stream all objects of the given type that the user has a relation with
description: "The Streamed ListObjects API is very similar to the the ListObjects API, with two differences: \n1. Instead of collecting all objects before returning a response, it streams them to the client as they are collected. \n2. The number of results returned is only limited by the execution timeout specified in the flag OPENFGA_LIST_OBJECTS_DEADLINE. \n"
operationId: StreamedListObjects
responses:
'200':
description: A successful response.(streaming responses)
schema:
type: object
properties:
result:
$ref: '#/definitions/StreamedListObjectsResponse'
error:
$ref: '#/definitions/Status'
title: Stream result of StreamedListObjectsResponse
'400':
description: Request failed due to invalid input.
schema:
$ref: '#/definitions/ValidationErrorMessageResponse'
'401':
description: Not authenticated.
schema:
$ref: '#/definitions/UnauthenticatedResponse'
'403':
description: Forbidden.
schema:
$ref: '#/definitions/ForbiddenResponse'
'404':
description: Request failed due to incorrect path.
schema:
$ref: '#/definitions/PathUnknownErrorMessageResponse'
'409':
description: Request was aborted due a transaction conflict.
schema:
$ref: '#/definitions/AbortedMessageResponse'
'422':
description: Request timed out due to excessive request throttling.
schema:
$ref: '#/definitions/UnprocessableContentMessageResponse'
'500':
description: Request failed due to internal server error.
schema:
$ref: '#/definitions/InternalErrorMessageResponse'
parameters:
- name: store_id
in: path
required: true
type: string
- name: body
in: body
required: true
schema:
type: object
properties:
authorization_model_id:
type: string
example: 01G5JAVJ41T49E9TT3SKVS7X1J
type:
type: string
example: document
relation:
type: string
example: reader
user:
type: string
example: user:anne
maxLength: 512
minLength: 1
contextual_tuples:
$ref: '#/definitions/ContextualTupleKeys'
context:
type: object
description: 'Additional request context that will be used to evaluate any ABAC conditions encountered
in the query evaluation.'
consistency:
$ref: '#/definitions/ConsistencyPreference'
description: Controls the consistency preference for this request. Default value is UNSPECIFIED, which will have the same behavior as MINIMIZE_LATENCY.
required:
- type
- relation
- user
tags:
- Relationship Queries
definitions:
TupleKey:
type: object
properties:
user:
type: string
example: user:anne
maxLength: 512
relation:
type: string
example: reader
maxLength: 50
object:
# --- truncated at 32 KB (44 KB total) ---
# Full source: https://raw.githubusercontent.com/api-evangelist/openfga/refs/heads/main/openapi/openfga-relationship-queries-api-openapi.yml