`GET /api/principals`

List principals of one type.

Lists every principal of the named type.

type is REQUIRED and there is no untyped listing. With no type the key server would query the abstract umbrella class, which has no name column of its own and five real subclasses, so the answer could be neither ordered nor bounded.

The READABLE set is wider than the CREATABLE one by exactly two types: xauth is listable here and created at POST /api/principals/xauth; certificate is listable here and created only by ENROLMENT at POST /api/certificates/enroll, never by name.

Each row carries its id in both spellings -- see the Principal schema, because using the wrong one on the next call is the commonest mistake in this family.

Paged and filtered by limit, offset and a name PREFIX (TE81-416). limit is ceilinged by REFUSAL, not by clamping: 501 is a 400 and not a page of 500, because a silently reduced page is indistinguishable from a short last page. offset without limit is a 400 too -- the key server gates the whole limit clause on a positive top, so an offset sent alone is discarded and page one comes back while the caller believes it asked for page two.

There is still no total: the key server returns rows, never a cardinality. A next page exists only if this one came back FULL, which means the last page of an exact multiple looks full and costs one short request to discover.

Above 1,024 objects an unwindowed listing is REFUSED by the key server (ADR-0095), naming the limit -- one package carries at most that many persistent objects. Page it.

Authentication

Send the session id as Authorization: Bearer <session id>, and an RFC 9449 DPoP proof in the DPoP header if your session is bound to a key. The two are required together, not as alternatives — see Authenticating and Proving you hold your key.

This surface sets no cookie

There is no session cookie on any response and none is read on any request. Do not set credentials: "include" on a browser fetch.

Parameters

Name	In	Required	Type	Description
`type`	query	yes	`string` (`password`, `certificate`, `ldap`, `xauth`, `group`)
`limit`	query	no	`integer`	Page size, 1..500. Above 500 is a 400, never a smaller page.
`offset`	query	no	`integer`	Rows to skip. REQUIRES limit -- sent alone it is a 400.
`name`	query	no	`string`	A name PREFIX. The key server appends the SQL wildcard; do not append one here. The listing is ordered by the same column it filters on.

Request

No request body.

Responses

`200`

The principals of that type.

Field	Type	Required	Description
`type`	`string`	yes
`className`	`string`	yes	The key server class this type maps to.
`count`	`integer`	yes
`principals`	array of `Principal`	yes	A principal, carrying its id in BOTH spellings because different routes take different ones. `id` (16 hex digits) is what this API's `{id}`, `{gid}` and `{pid}` path segments take; `principalId` (a decimal string of the same eight bytes) together with `systemId` is what the ACL and export routes take.
`page`	`object`	yes	What the server actually applied. `pattern` is the point of it: a LIKE that matched nothing and a LIKE that was never sent both answer an empty list, so echoing the pattern that really went on the wire is what makes an empty result legible. `applied` is false when no window was asked for.
`detail`	`string`	no

page object

Field	Type	Required
`applied`	`boolean`	yes
`limit`	`integer`	yes
`offset`	`integer`	yes
`name`	`string`	yes
`pattern`	`string`	yes
`orderedBy`	`string`	no

Example

{
  "type": "...",
  "className": "...",
  "count": 0,
  "principals": [
    {
      "id": "...",
      "principalId": "...",
      "systemId": 0,
      "className": "...",
      "name": "...",
      "disabled": true,
      "roleIds": [
        "..."
      ],
      "groupIds": [
        "..."
      ]
    }
  ],
  "page": {
    "applied": true,
    "limit": 0,
    "offset": 0,
    "name": "...",
    "pattern": "...",
    "orderedBy": "..."
  },
  "detail": "..."
}

`400`

BAD_REQUEST -- type absent or not one of the five. The detail names them.

`401`

No live session, a DPoP proof that did not verify, or a certificate session whose certificate the key server now refuses.

SESSION_NOT_FOUND -- the credential names no session this Gateway holds. SESSION_EXPIRED -- it aged out. Both carry reauth: true; obtain a new credential rather than retrying.

PROOF_* -- the sender constraint refused. See the DPoP section of this document for the full table; PROOF_MALFORMED is a 400 and PROOF_REPLAY_CACHE_FULL a 503, and the rest are here.

SCOPED_CREDENTIAL_EXPIRED -- a scoped browser credential passed its fixed lifetime. Use does not extend it: an idle timeout would be refreshed by exactly the traffic a stolen handle produces.

CERTIFICATE_REVOKED -- on a session established by certificate login, the key server re-checks the certificate that session was established with on its operations, and it is now named by revocation evidence (ADR 0115). detail is the key server's sentence. Every later operation of the session is refused the same way; log in with a different certificate.

`403`

Authenticated, and refused. The codes differ in what they say about where the refusal came from: ACCESS_DENIED, PRINCIPAL_DISABLED and DELEGATOR_REFUSED are the key server's -- the last one on a DELEGATED session whose delegator has since been disabled, lost its DELEGATION flag, been unenrolled or had its certificate revoked (ADR-0123); its detail is the key server's sentence naming the delegator, and no new login helps until an administrator restores it. REVOCATION_STATUS_UNAVAILABLE and REVOCATION_EVIDENCE_STALE are the key server's too, on a session established by certificate login: the same re-check found no current revocation evidence for that certificate's issuer under a policy that requires it (ADR 0115) -- the credential is not what was refused, and an operator importing a current CRL for the issuer is what helps -- while NOT_WRITABLE, BUILT_IN_PRINCIPAL, OWN_ACCOUNT and OBJECT_NOT_IN_CREDENTIAL_SCOPE are decided by the Gateway before anything is sent.

`500`

A fault rather than a refusal.

OP_FAILED is the catch-all: the key server refused in words that match no classified pattern, so the Gateway cannot say more than that the operation did not happen. Some key server refusals that are conceptually a caller error arrive here rather than as a 4xx, because the wire carries no distinguishing code -- where a route can recognise one from its message it maps it, and each such mapping is documented on the operation.

`503`

A capacity ceiling or a missing deployment prerequisite. retryable says which.

A scope of session or process names the ceiling that was hit, and the response carries Retry-After.

BUILD_NOT_ADMITTED (scope: process, retryable: true, Retry-After): the key server does not admit this Gateway's client build. Every key-server connection the Gateway opens attests the signed release it runs (TE_RELEASE_MANIFEST) right after it authenticates; while that attestation is refused -- the release is not registered at the key server's code-signing level, the level was raised under it, or the installed files no longer match the signed manifest -- every route but GET /api/health and GET /api/ready answers this, and detail names the cause. It is never a 401 or a 403: no credential or role of the caller's is at fault. The Gateway re-attempts on a timer and recovers without a restart once the key server admits it; GET /api/ready says when.

Error handling

Every failure answers JSON carrying at least code and detail. Match on code — detail is written for a human debugging the call and its wording is not part of the contract. See the error model.

Status	Meaning
`400`	`BAD_REQUEST` -- `type` absent or not one of the five. The detail names them.
`401`	No live session, a DPoP proof that did not verify, or a certificate session whose certificate the key server now refuses. `SESSION_NOT_FOUND` -- the credential names no session this Gateway holds. `SESSION_EXPIRED` -- it aged out. Both carry `reauth: true`; obtain a new credential rather than retrying. `PROOF_*` -- the sender constraint refused. See the DPoP section of this document for the full table; `PROOF_MALFORMED` is a `400` and `PROOF_REPLAY_CACHE_FULL` a `503`, and the rest are here. `SCOPED_CREDENTIAL_EXPIRED` -- a scoped browser credential passed its fixed lifetime. Use does not extend it: an idle timeout would be refreshed by exactly the traffic a stolen handle produces. `CERTIFICATE_REVOKED` -- on a session established by certificate login, the key server re-checks the certificate that session was established with on its operations, and it is now named by revocation evidence (ADR 0115). `detail` is the key server's sentence. Every later operation of the session is refused the same way; log in with a different certificate.
`403`	Authenticated, and refused. The codes differ in what they say about where the refusal came from: `ACCESS_DENIED`, `PRINCIPAL_DISABLED` and `DELEGATOR_REFUSED` are the key server's -- the last one on a DELEGATED session whose delegator has since been disabled, lost its DELEGATION flag, been unenrolled or had its certificate revoked (ADR-0123); its `detail` is the key server's sentence naming the delegator, and no new login helps until an administrator restores it. `REVOCATION_STATUS_UNAVAILABLE` and `REVOCATION_EVIDENCE_STALE` are the key server's too, on a session established by certificate login: the same re-check found no current revocation evidence for that certificate's issuer under a policy that requires it (ADR 0115) -- the credential is not what was refused, and an operator importing a current CRL for the issuer is what helps -- while `NOT_WRITABLE`, `BUILT_IN_PRINCIPAL`, `OWN_ACCOUNT` and `OBJECT_NOT_IN_CREDENTIAL_SCOPE` are decided by the Gateway before anything is sent.
`500`	A fault rather than a refusal. `OP_FAILED` is the catch-all: the key server refused in words that match no classified pattern, so the Gateway cannot say more than that the operation did not happen. Some key server refusals that are conceptually a caller error arrive here rather than as a `4xx`, because the wire carries no distinguishing code -- where a route can recognise one from its message it maps it, and each such mapping is documented on the operation.
`503`	A capacity ceiling or a missing deployment prerequisite. `retryable` says which. A `scope` of `session` or `process` names the ceiling that was hit, and the response carries `Retry-After`. `BUILD_NOT_ADMITTED` (`scope: process`, `retryable: true`, `Retry-After`): the key server does not admit this Gateway's client build. Every key-server connection the Gateway opens attests the signed release it runs (`TE_RELEASE_MANIFEST`) right after it authenticates; while that attestation is refused -- the release is not registered at the key server's code-signing level, the level was raised under it, or the installed files no longer match the signed manifest -- every route but `GET /api/health` and `GET /api/ready` answers this, and `detail` names the cause. It is never a `401` or a `403`: no credential or role of the caller's is at fault. The Gateway re-attempts on a timer and recovers without a restart once the key server admits it; `GET /api/ready` says when.

Authentication​

Parameters​

Request​

Responses​

200​

400​

401​

403​

500​

503​

Error handling​