vault

Read many heads' exact stored bytes in one call

The batched sibling of GET /vaults/v1/{vault_id}/heads/{generation}. Heads are generation-addressed and therefore cannot ride the carrier-only object-reads batch, so a cold chain walk otherwise pays one round trip per generation for bytes that are ~1.2 KB each; one POST carries a whole listing page. stored_bytes is base64url of the EXACT stored bytes — byte-identical to the per-generation route, and the same encoding the composite state read's head.stored_bytes uses. All-or-nothing: any requested generation with no stored head refuses the WHOLE batch with RESOURCE_NOT_FOUND naming the first absent one in request order; no partial page is ever served. Nothing here is server-verified or re-serialized — hash what was served, exactly as on every other stored-bytes read. Never lifecycle-gated.

post/vaults/v1/{vault_id}/head-reads

Request

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

Path parameters

vault_idstring required

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

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

generationsstring[] required

1 to 1000 generations, STRICTLY ASCENDING. Anything else refuses VALIDATION_FAILED before any storage read.

Response

Each requested head's exact stored bytes, in request order

formatstring
repo_idstring

Example response

{
  "format": "r402s/v0"
}

Changes

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