POST /api/crypto/hmac

Run one or more HMAC stages.

Runs the HMAC stages named by mask -- a bitwise OR of the init, update and final stage constants.

Four refusals exist because the key server would otherwise accept the request and quietly do nothing useful:

• mask: 0 selects no stage at all -- a well-formed instruction to do nothing;
• an init stage with no hiddenLink never installs a key, and every later stage then silently no-ops;
• an iv without an init stage is never looked at, so it would be silently discarded;
• a mask outside 0..255 is not a stage set.

WARNING: mac: null is a real answer, not an empty MAC. The key server writes the finished MAC back into a reply slot in place, so a stage that produces none leaves nothing there. For a stage other than final, the returned buffer is whatever the server wrote, not necessarily a MAC.

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

Field	Type	Required	Description
mask	integer	yes	OR of the HMAC stage constants. The 400 detail names their values.
data	string	no	Canonical base64. Optional.
hiddenLink	string	no	Canonical base64. REQUIRED when the mask includes the init stage.
iv	string	no	Canonical base64. Only read when the mask includes the init stage.

Example

{
  "mask": 0,
  "data": "...",
  "hiddenLink": "...",
  "iv": "..."
}

Responses

200

The stages ran.

Field	Type	Required	Description
mask	integer	yes
stages	object	yes
mac	string or null	yes	base64
macBytes	integer or null	yes
detail	string	yes

stages object

Field	Type	Required	Description
init	boolean	no
update	boolean	no
final	boolean	no

Example

{
  "mask": 0,
  "stages": {
    "init": true,
    "update": true,
    "final": true
  },
  "mac": "...",
  "macBytes": 0,
  "detail": "..."
}

400

The request was refused before anything was sent to the key server.

Most 400s on this surface carry code: BAD_REQUEST and a detail naming the field and saying what the key server would otherwise have done with it. A large share of them exist because the value would have been ACCEPTED downstream and quietly meant something else -- an empty string that reaches the wire as "mint a new key", a zero-length identifier that names no object, a numeric flag word that clears bits the caller did not name.

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

OBJECT_NOT_IN_CREDENTIAL_SCOPE or ACCESS_DENIED.

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	The request was refused before anything was sent to the key server. Most 400s on this surface carry code: BAD_REQUEST and a detail naming the field and saying what the key server would otherwise have done with it. A large share of them exist because the value would have been ACCEPTED downstream and quietly meant something else -- an empty string that reaches the wire as "mint a new key", a zero-length identifier that names no object, a numeric flag word that clears bits the caller did not name.
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	OBJECT_NOT_IN_CREDENTIAL_SCOPE or ACCESS_DENIED.
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.