vault

First-seen pin confirmation (owner + step-up)

Owner + step-up (gitvault.rotate, protocol rev 42 D197). Issues a recipient_confirmation_receipt with purpose:"first_pin" for a principal with NO currently-admitted pin on this vault — a principal who already has one must use the repin route instead (409 RECIPIENT_SET_MISMATCH). The receipt is single-use and must be cited by the matching entry of the recipient_pin_manifest the rotation eventually admits. IDEMPOTENT (rev 43 D206): a repeated call for the identical (principal, new_fingerprint, currently-effective base manifest, recipient_state_version) tuple returns 200 with the SAME previously-issued receipt rather than minting a second one.

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

Request

  • Base URL: https://api.run402.com
  • URL: https://api.run402.com/vaults/v1/{vault_id}/recipients/{principal_id}/confirm
  • 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 confirmation 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

new_fingerprintstring required

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

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.