vault

Presign reads for stored objects

Ciphertext never streams through the gateway — reads are presigned GETs straight to storage, each returned with the ledger's recorded stored_bytes_sha256 and size_bytes so the client verifies what it downloaded. key_envelope reads are RECIPIENT-ONLY: a fingerprint that is not one of the caller's own registered encryption keys is refused 403 VAULT_ACCESS_DENIED, and that check runs BEFORE the ledger lookup, so the refusal never reveals whether such an envelope exists. An object that is absent, of a different kind, or already tombstoned (DELETING / DELETED / PRUNE_AUTHORIZED_PRESENT) is 404 RESOURCE_NOT_FOUND. Never lifecycle-gated. Five immutable ciphertext kinds (wal_pack, ref_state, retention_roots, checkpoint_manifest, checkpoint_pack) additionally carry edge_url — a CloudFront-signed URL for the SAME bytes at the SAME expires_at — whenever the platform's optional edge cache is configured; every other kind, and every deployment without edge caching configured, simply omits the field. edge_url is ADDITIVE, never a replacement for url: url is always present and unchanged (the S3 presign), so an existing client that ignores edge_url keeps working byte-for-byte. A client that prefers the edge tries edge_url first and falls back to url on any failure (4xx/5xx/timeout), silently, since both name the identical hash-verified bytes. Edge-served bytes are ciphertext only, verified client-side exactly like the S3 presign — the edge is never part of the trust model. A pruned or purged object stops being served from BOTH paths within a bounded window: the origin 404s immediately post-deletion, and the edge cache's own TTL (1 hour) is the declared worst-case bound on a stale edge hit. Every entry additionally MAY carry inline — base64url of the object's EXACT stored bytes — present only when size_bytes is at or under a fixed per-object cap AND the response's running total inline budget is not yet spent (decided in request order, so earlier entries win the budget); url/edge_url stay present and unchanged on every entry regardless, and a gateway-side storage read failure for one entry just omits its inline, never fails the batch — size-gated, never kind-gated, so key_envelope inlines too once past its recipient-only check above.

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

Request

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

Response

Presigned reads, in request order

Changes

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