API reference

Check the caller's own permissions

Operation ID: checkPermission

"May I do this?", answered for the caller themselves. Served on the tenant's own origin, not the Management API host: the bearer token is the tenant's own end-user access token (the dashboard reaches it with its session instead), and the host names the tenant, so nothing in the request can disagree with the credential. Requires no scope — authentication is the floor, and the answer is never more than the caller's own permissions in a scope they named. It exists for what the token's `permissions` claim cannot cover: an organization the token was not issued in, any resource-level question (resource grants never ride a credential), and a live answer for a reader of a JWT access token, whose claims were fixed when it was signed. Omitting `resource` asks the credential's own scope — the organization it was issued for plus tenant scope, the same scope the `permissions` claim resolved — so a JWT reader needs to echo nothing, and a credential carrying no organization still gets tenant scope alone. The organization is read from the credential and can never be named by the request. Naming one of your own resources is narrower: tenant-wide roles plus grants on that instance, with no organization half. There is no `subject` field — asking about someone else needs an authority model, not a scopeless floor — and a machine credential is refused 403 rather than answered about its application's owner.

Servers

• https://{tenantId}.udibo.com

Authentication

Use every scheme in this requirement.

1. • oauth2

     OAuth 2.0 authentication required

     No named scope is required by this scheme.

Check the description and required headers; this does not establish public access.

Parameters

No parameters are declared.

Request body

Responses

Full object schemas and examples are in the OpenAPI document.