> ## Documentation Index > Fetch the complete documentation index at: https://docs.openpayload.io/llms.txt > Use this file to discover all available pages before exploring further. # OpenPayload Cache API > Temporarily store and retrieve encrypted messages for recipients who are not immediately reachable A Cache is temporary, policy-governed storage for encrypted DDN envelopes. It helps a recipient receive messages after reconnecting without giving the Cache access to plaintext. `Store` policy steps target `OpenPayloadCacheService`. `Archive` steps target a distinct `OpenPayloadArchiveService`. An operator can publish both service entries with the same physical endpoint, but the policy must reference the ID whose type matches the step. Archive routing remains subject to the same effective TTL and does not create indefinite storage. ## Typical flow 1. A sender submits an original encrypted envelope to a Relay. 2. A winning `Store` or `Archive` action can place policy-authorized copies at the named services. 3. The Cache enforces the selected finalized policy decision, expiration, and effective constraints without decrypting the payload. 4. The recipient signs a short retrieval proof. 5. The recipient calls a messages or chunks endpoint. 6. After safely persisting the encrypted message locally, the recipient acknowledges it at the Cache from which it retrieved that copy. ## Policy and expiration checks A Cache does not trust client-supplied policy provenance. The network validates the selected policy revision, compatible service target, message limits, expiration, and any Store replica placement before accepting a policy-delivered copy. Archive remains a distinct policy action and service type, but its node-to-node transport is outside the public client contract. A direct `POST /cache/store` request is valid only when finalized policy resolution confirms normal DID-service fall-through and the recipient's DID authorizes that Cache. A Directory or chain lookup failure must not be treated as an absent policy. The Relay computes one absolute `expires_at` value. Every stored copy uses that value as a hard upper bound, and no Cache extends it during forwarding, replication, or retrieval. A Cache may purge earlier after acknowledgement or when current public authorization or placement no longer permits retention. Expired envelopes are purged even when the recipient never collects them. ## Why retrieval needs a proof Knowing a DID is public information. It must not be sufficient to download that DID's cached messages. Retrieval and acknowledgement use an Ed25519 proof from a verification method authorized by the recipient's `OpenPayloadCacheService`. Resolve the recipient DID and select the `OpenPayloadCacheService` entry. Its `serviceEndpoint` contains the Cache base URL, its `id` becomes the request's Cache service ID, and its `authorization` array identifies which published Ed25519 verification methods may sign access proofs. Follow the Cache endpoint, service ID, and authorized verification key in one complete example. The proof binds the operation to: * Recipient DID and device * Cache service and exact endpoint * Authorized key * Timestamp and one-time nonce * Requested subject, such as all messages, a chunk group, or sorted message IDs ## Replicated messages A policy can request as many as four Cache replicas, subject to lower DID, Persona, or rule limits. A Relay result reports observed `Store` accepts in `details.accepted_caches`; `Archive` accepts use the separate `details.accepted_archives` field. Neither list includes later accepts after a `Forward` step, and neither is embedded in the recipient's stored envelope. Acknowledgement is per Cache: after the client safely persists or processes a retrieved Cache copy, send the signed acknowledgement to the Cache that returned it. If one acknowledgement fails, retry while that Cache still holds the copy and before `expires_at`. Do not assume retention until that time: an authorization or placement change can permit earlier purge. ## Important limitations Cache response objects currently include a proof model whose `reason` and `signature` fields are optional and absent when they are not populated. Treat an unsigned proof as event metadata, not a cryptographically verifiable Cache receipt, until node signing is enabled. ## Straight to the point ```text theme={null} Store: POST /cache/store Retrieve: GET /cache/messages/{did}[/{deviceId}] Chunks: GET /cache/chunks/{did}/{messageGroupId} Delete acknowledged messages: POST /cache/ack Replica rule: acknowledge each Cache from which the recipient retrieves a copy ``` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.