Trust & Data · API module

Data Vault

Navigate minimized owner-scoped metadata, and use the separately authenticated application file API for client-encrypted uploads, exact-file owner-approved backend decryption and commitment-only mainnet evidence. General grants, versions, retention and erasure remain separately planned contracts. This works without making the gateway a storage owner, key custodian or cleartext proxy.

BUSINESS CASES

Where this module fits

protected document inventory and bounded directory navigation
client-encrypted multipart storage
purpose- and recipient-bound retrieval
controlled sharing and grant revocation
retention, recycle, restore, and cryptographic-erasure governance
private-to-public evidence reconciliation

PRIMARY CONSUMERS

Who integrates it

workspace data owners
records and compliance systems
document-processing agents
evidence and disclosure integrations

PREREQUISITES

What must exist first

Existing owner metadata reads use vault:read and the native bearer-derived active workspace.
Partner files use a registered Vault-enabled confidential app, exact owner-consented vault:files:upload/read scopes, owner protection and separate selected-file approval.
Owner passwords, MFA/native sessions and private protection keys stay on the owner device; only app-scoped credentials reach the backend.
Each application supplies its exact production HTTPS origin/callback; test fixture callbacks are not production registration.
General lifecycle/grant/retention/recycle/restore/erasure contracts remain planned until individually promoted; no MPC wallet is required for this accepted file flow.

RECOMMENDED WORKFLOW

Compose the module safely.

01
For owner metadata navigation use the existing native bearer and vault:read; never submit a Vault selector. Traverse one bounded level at a time.
02
For partner files, follow the API-only Data Vault integration guide: owner signup/sign-in, first MFA, protected Vault, app registration and explicit connection authorization.
03
Prepare a stable app-owner file ID, encrypt locally and persist exact registration/chunks before upload; reuse them on uncertain retries.
04
Request exact-file decryption separately; the owner reviews and approves locally with fresh MFA before the backend receives its wrapped file key.
05
Retrieve and decrypt only currently approved app-created files; renew short tokens only within original current owner authority.
06
Verify new mainnet evidence independently. File/app/source revocation stops further access; do not infer a general grant, deletion or archival contract.

AGENT INTEGRATION

Machine-use boundaries

Keep cleartext content, base64 payloads, encryption or decryption material, object names, recipient identities, tickets, opaque content roots, private storage endpoints, and raw storage metadata out of shared prompts, logs, analytics, caches, URLs, and agent memory.
Use stable object identifiers for navigation and reconciliation; names and paths are mutable presentation values and never authorization keys.
Treat storage_readiness=READY, encrypted_content_root, shard counts, event commitments, and anchor state as limited posture. None grants download, decryption, sharing, disclosure, retention change, restore, or erasure authority.
A sharing invitation is not a grant, a grant is not delivery, a ticket is not decryption authority, revocation cannot claw back previously obtained cleartext, and a database deleted flag or IPFS unpin is not cryptographic-erasure proof.
Traverse deliberately with bounded depth and re-read current owner or grant state before every dependent action; another workspace's object must remain indistinguishable from a missing object.
The ten legacy /api/v2/quantum/storage/* POST routes are bodyless 501 migration markers. Do not translate their legacy bodies or infer canonical request schemas from caller-selected vault IDs, base64 content, raw metadata, or direct-download behavior.
Never call a planned modern lifecycle contract until its exact operation appears in the live production OpenAPI document.
POST /api/v2/data-vault/files is a separate, production-listed app-scoped flow. Follow /api-reference/v2/guides/data-vault; basic ciphertext read consent alone does not authorize plaintext processing or Cortex knowledge import.

Register only production-listed routes as executable tools, and re-fetch the deployed OpenAPI before generating or sending a request. Source-ready routes awaiting deployment are preparation references; planned contracts are non-executable.

VERIFIED API-ONLY INTEGRATION

Data Vault integration: owner setup, explicit app and selected-file consent, encrypted uploads, backend retrieval/decryption and independent mainnet proof verification. Five synthetic owners completed the public API flow without a web interface or MPC wallet.

Read the complete developer guide, payloads and runnable example

Endpoint reference

Explore this module’s endpoints.

Check each endpoint’s availability and required permissions. Planned routes and routes awaiting deployment are preparation references, not callable APIs.