Skip to main content

POST /api/roles

Create a role carrying a set of operations.

Creates a role and verifies by a fresh read that asserts BOTH the name AND the operation set -- so a role created under the right name holding none of the requested operations arrives as a 409 rather than a 200.

Omitting operations creates a role that grants nothing. That is stated explicitly in the response rather than passed over, because a role holding zero operations is exactly what a silently-dropped operations array also looks like.

Nobody holds the new role: assign it with PUT /api/principals/{id}/roles.

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.

Request

FieldTypeRequiredDescription
namestringyes
operationsarray of stringnoOperation ids from GET /api/operations. They are assigned by the key server and there is no published table, which is why that route exists.

Example

{
"name": "...",
"operations": [
"..."
]
}

Responses

200

Created, with the operation set verified by a fresh read.

FieldTypeRequiredDescription
namestringyes
requestedOperationsarray of stringyes
savedbooleanyes
roleobject or nullno
detailstringno

role object

FieldTypeRequiredDescription
idstringno
namestringno
builtInboolean or nullno
operationsarray of stringno

Example

{
"name": "...",
"requestedOperations": [
"..."
],
"saved": true,
"role": {
"id": "...",
"name": "...",
"builtIn": true,
"operations": [
"..."
]
},
"detail": "..."
}

400

BAD_REQUEST -- name empty, or operations not an array of 16-hex-digit ids. The empty-name refusal agrees with the key server's own rather than pre-empting a different answer; it just names the field.

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.

409

NAME_IN_USE -- a role with that name already exists, established by reading the catalogue first. Or the fresh read does not agree with what was requested, in name or in operation set.

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 codedetail is written for a human debugging the call and its wording is not part of the contract. See the error model.

StatusMeaning
400BAD_REQUEST -- name empty, or operations not an array of 16-hex-digit ids. The empty-name refusal agrees with the key server's own rather than pre-empting a different answer; it just names the field.
401No 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.
403Authenticated, 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.
409NAME_IN_USE -- a role with that name already exists, established by reading the catalogue first. Or the fresh read does not agree with what was requested, in name or in operation set.
500A 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.
503A 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.