Admit a signed head (the push)
THE write path. stored_bytes is canonical base64url of the exact signed object as it will be stored; stored_bytes_sha256 is your own hash of those bytes and is checked before the protocol machine sees anything, so a transport corruption reads as a request-shape refusal rather than a signature failure. The generation is won by a create-only compare-and-swap on the admission record: a loser gets 409 HEAD_CAS_CONFLICT carrying details.winner as hashes only — re-read the winner from GET /vaults/v1/{vault_id}/admissions/{generation}, verify it yourself, rebase, and push again. 201 means the generation is yours. 202 means the record write is not yet resolved and the platform reconciler is driving it to completion — poll, never re-push. A head carrying a repair descriptor additionally requires gitvault.repair (owner + step-up), decided from the signed bytes rather than from the URL.
Request
- Base URL: https://api.run402.com
- URL: https://api.run402.com/vaults/v1/{vault_id}/admissions
- Auth: one of:
- API key in header SIGN-IN-WITH-X
- HTTP bearer
- HTTP bearer
Path parameters
The vault id (src_<32 hex>); the wire field is repo_id (protocol D185).
Headers
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
Response
The generation is won (the admission record CAS succeeded)
Changes
No recorded changes to this operation across all 1 revision of this API.