DELETE /api/principals/{id}

Remove a principal -- DISABLING it first and REASSIGNING ITS KEYS to a recipient.

WARNING: this does considerably more than the path suggests, and the extra work is not optional. Removing a principal REASSIGNS ITS KEYS to another principal, and the handler performs a two-step sequence:

1. if the principal is enabled, it is DISABLED and that disable is written;
2. it is then removed, with its keys reassigned to the recipient.

If step 2 fails, the principal is left DISABLED and still present. The 409 says so and reports what the re-read between the two steps saw. This is not a rollback-safe operation and there is no undo.

The recipient defaults to the calling session's own user. Name a different one with ?recipient=<name>.

WARNING: the recipient lookup resolves PASSWORD principals ONLY. A group, a certificate principal and an XAuth id are all unresolvable as recipients even when they exist. In particular, on a DELEGATED session the session user IS an XAuth id, so the default can never resolve there and ?recipient= must be given. When the lookup fails nothing is written -- the principal is untouched and still enabled.

On success the answer is 204 with no body.

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
id	path	yes	string	A principal id as 16 hex digits. This is the id field of a principal projection -- NOT the principalId decimal string beside it. The two are the same eight bytes in two spellings, and only the hex one is a path segment.
recipient	query	no	string	The name of the PASSWORD principal that inherits this principal's keys. Omit to use the calling session's own user. Must not be empty if given.

Request

No request body.

Responses

204

The principal is gone and its keys were reassigned. Verified by a fresh read.

400

BAD_REQUEST -- the id is not 16 hex digits, or recipient was given as an empty string.

401

No live session, or a DPoP proof that did not verify.

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.

403

Authenticated, and refused. The codes differ in what they say about where the refusal came from: ACCESS_DENIED and PRINCIPAL_DISABLED are the key server's, while NOT_WRITABLE, BUILT_IN_PRINCIPAL, OWN_ACCOUNT and OBJECT_NOT_IN_CREDENTIAL_SCOPE are decided by the Gateway before anything is sent.

404

NOT_FOUND -- no such principal. Nothing was written.

409

NO_RECIPIENT -- none was named and the session carries no user name. Nothing was written.

NO_SUCH_RECIPIENT -- the named (or defaulted) recipient could not be resolved. Nothing was written: the principal is untouched and still enabled. recipientWasDefaulted says whether you named it.

NOT_SAVED -- the principal was still present when read back after removal. It may now be disabled: step one had already run. disabledOnReRead reports what the re-read between the two steps saw.

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.

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 -- the id is not 16 hex digits, or recipient was given as an empty string.
401	No live session, or a DPoP proof that did not verify. 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.
403	Authenticated, and refused. The codes differ in what they say about where the refusal came from: ACCESS_DENIED and PRINCIPAL_DISABLED are the key server's, while NOT_WRITABLE, BUILT_IN_PRINCIPAL, OWN_ACCOUNT and OBJECT_NOT_IN_CREDENTIAL_SCOPE are decided by the Gateway before anything is sent.
404	NOT_FOUND -- no such principal. Nothing was written.
409	NO_RECIPIENT -- none was named and the session carries no user name. Nothing was written. NO_SUCH_RECIPIENT -- the named (or defaulted) recipient could not be resolved. Nothing was written: the principal is untouched and still enabled. recipientWasDefaulted says whether you named it. NOT_SAVED -- the principal was still present when read back after removal. It may now be disabled: step one had already run. disabledOnReRead reports what the re-read between the two steps saw.
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.