Consents

The register of who is connected to your application, with which scopes, since when — metadata only, never claim values.

The consent register

GET /v1/developer/applications/{applicationId}/consents is a server-paginated list of the consents granted to the application. page and pageSize (at most 100) page it; status filters it. The answer carries items, page, pageSize, total and a counts object with the number of consents in each status.

GET …/consents/{consentId} is one consent. Both are readable by the owner, admin and developer roles, and both are session-bound developer routes: the application's Consents screen (/applications/<applicationId>/consents) is where you page through them.

Page through the register (what the console reads)

GET /v1/developer/applications/{applicationId}/consents?page=1&pageSize=50

What is and is not in it

An entry is the consent as a record: its id, status, version, the scopes it covers, when it was granted and, if it ended, when and how. The person is named by the pairwise sub your application already knows them by.

Hearing about changes

A consent is granted on the consent screen and ends when the person disconnects your application; there is no scope-level revocation. The consent.granted and consent.revoked webhook events carry the consent id, status, scopes and the person's sub — see Revocation and webhooks.

What this does not do

You cannot end a consent from here. Only the person disconnects. In the sandbox, resetting a test identity ends its consents.
Sandbox consents are test consents. A test identity's connection appears here like any other; nothing about it describes a real person.

Verified against API commit 234dba22 on 2026-10-18. The routes, scopes, checklist, events and limits on these pages are read from that export, not typed.