vault

Re-pin ceremony (owner + step-up)

Owner + step-up (gitvault.rotate, protocol rev 42 D197). Issues a recipient_confirmation_receipt with purpose:"repin" — old_ek_fingerprint MUST equal this principal's currently-admitted pin exactly, or the call refuses 409 RECIPIENT_SET_MISMATCH naming what is actually pinned. IDEMPOTENT (rev 43 D206), same 200-vs-201 convention as /confirm.

post/vaults/v1/{vault_id}/recipients/{principal_id}/repin

Request

  • Base URL: https://api.run402.com
  • URL: https://api.run402.com/vaults/v1/{vault_id}/recipients/{principal_id}/repin
  • Auth: one of:
    • API key in header SIGN-IN-WITH-X
    • HTTP bearer

Path parameters

vault_idstring required

The vault id (src_<32 hex>); the wire field is repo_id (protocol D185).

principal_idstring required

The recipient principal this re-pin is FOR — not the caller's own principal.

Headers

SIGN-IN-WITH-Xstring required

SIWX auth header — base64-encoded JSON payload containing a signed CAIP-122 (EIP-4361) message. See https://docs.x402.org/extensions/sign-in-with-x.

Request body

old_ek_fingerprintstring required

MUST equal this principal's currently-admitted ek_… fingerprint exactly.

new_fingerprintstring required

The recipient's new ek_<32 hex> encryption-key fingerprint.

Response

rev 43 D206 — idempotent replay of the SAME previously-issued receipt for this identical tuple

object required

Changes

No recorded changes to this operation across all 1 revision of this API.