KesselInventoryService_CheckBulk

POST

/api/kessel/v1beta2/checkbulk

Performs bulk permission checks for multiple resource-subject-relation combinations.

This API is more efficient than making individual Check calls when verifying permissions for multiple items. It answers questions like: “Which of these resources can subject X perform action Y on?”

Common use cases include:

• Filtering lists based on user permissions
• Batch authorization checks before performing bulk operations
• Dashboard rendering with multiple permission checks
• Pre-authorization for UI components

The response includes a result for each item in the request, maintaining the same order.

Request Body ^required

CheckBulkRequest allows checking multiple permissions in a single request. This is more efficient than making individual Check calls when verifying permissions for multiple resource-subject-relation combinations.

object

items

Array<object>

CheckBulkRequestItem represents a single permission check in a bulk request.

object

object

object

resourceType

string

resourceId

string

reporter

object

type

string

instanceId

string

relation

string

subject

A reference to a Subject or, if a relation is provided, a Subject Set.

object

relation

An optional relation which points to a set of Subjects instead of the single Subject. e.g. “members” or “owners” of a group identified in subject.

string

resource

object

resourceType

string

resourceId

string

reporter

object

type

string

instanceId

string

consistency

Defines how a request is handled by the service. If consistency is omitted by the client, standard server configuration uses minimize_latency by default, but deployments may override that default (for example, to at_least_as_acknowledged).

object

minimizeLatency

The service selects the fastest snapshot available. Must be set true if used.

boolean

atLeastAsFresh

All data used in the API call must be at least as fresh as found in the ConsistencyToken. More recent data might be used if available or faster.

object

token

string

atLeastAsAcknowledged

All data used in the API call must be at least as acknowledged, meaning it includes data up to the latest write known to Inventory. This aligns with ReportResource write visibility: when write_visibility=IMMEDIATE, the write waits for acknowledgement, so a subsequent read with at_least_as_acknowledged is guaranteed to be at least as recent as that write. Some deployments may use this behavior as the server-side default when consistency is omitted. Must be set true if used.

boolean

Responses

200

OK

CheckBulkResponse contains the results of all permission checks in the request.

object

pairs

Array<object>

CheckBulkResponsePair associates a request item with its corresponding result.

object

request

CheckBulkRequestItem represents a single permission check in a bulk request.

object

object

object

resourceType

string

resourceId

string

reporter

object

type

string

instanceId

string

relation

string

subject

A reference to a Subject or, if a relation is provided, a Subject Set.

object

relation

An optional relation which points to a set of Subjects instead of the single Subject. e.g. “members” or “owners” of a group identified in subject.

string

resource

object

resourceType

string

resourceId

string

reporter

object

type

string

instanceId

string

item

CheckBulkResponseItem represents the result of a single permission check.

object

allowed

string format: enum

Allowed values: ALLOWED_UNSPECIFIED ALLOWED_TRUE ALLOWED_FALSE

error

The Status type defines a logical error model that is suitable for different programming environments, including REST APIs and RPC APIs. It is used by gRPC. Each Status message contains three pieces of data: error code, error message, and error details. You can find out more about this error model and how to work with it in the API Design Guide.

object

code

The status code, which should be an enum value of [google.rpc.Code][google.rpc.Code].

integer format: int32

message

A developer-facing error message, which should be in English. Any user-facing error message should be localized and sent in the [google.rpc.Status.details][google.rpc.Status.details] field, or localized by the client.

string

details

A list of messages that carry the error details. There is a common set of message types for APIs to use.

Array<object>

Contains an arbitrary serialized message along with a @type that describes the type of the serialized message.

object

@type

The type of the serialized message.

string

key

additional properties

any

consistencyToken

object

token

string

default

Default error response

The Status type defines a logical error model that is suitable for different programming environments, including REST APIs and RPC APIs. It is used by gRPC. Each Status message contains three pieces of data: error code, error message, and error details. You can find out more about this error model and how to work with it in the API Design Guide.

object

code

The status code, which should be an enum value of [google.rpc.Code][google.rpc.Code].

integer format: int32

message

A developer-facing error message, which should be in English. Any user-facing error message should be localized and sent in the [google.rpc.Status.details][google.rpc.Status.details] field, or localized by the client.

string

details

A list of messages that carry the error details. There is a common set of message types for APIs to use.

Array<object>

Contains an arbitrary serialized message along with a @type that describes the type of the serialized message.

object

@type

The type of the serialized message.

string

key

additional properties

any