Private file access

Every file uploaded during KYC, organisation onboarding, or admin review is stored under a scoped object key and never exposed as a public URL. The Platform API returns an error response before reading storage when a request arrives without a valid session, uses an out-of-scope key, or references a missing object.

Read this page when you need to understand why a private file link works for one user and fails for another. For operator steps, see Open private files.

Do not build private file URLs by guessing object keys. Use the workflow that returns or records the file reference, then request the returned URL from your authenticated Console session. The URL is tied to Console authentication and object-key scope. Sharing the path with another user does not grant access unless that user also holds the required session and scope. A denied request returns an error response instead of exposing the stored object.

Access model

Object-key scopes

DALP allows private reads only for recognised object-key scopes. Each scope ties the readable path to a specific user identity or organisation, so access to one scope does not grant reads on objects belonging to another. Use the table below to identify which scope applies to your request.

Object keys are normalised before access checks. If your key contains . or .. path segments, the Platform API rejects the request to prevent traversal outside the allowed object-key namespace.

Request behaviour

The private file route supports GET and HEAD. HEAD returns metadata headers without the file body. GET returns the file body and metadata headers.

HEAD /dalp/private/kyc/user_123/version_456/document_789/envelope.json

When access is allowed and the object exists, DALP returns metadata headers such as:

200 OK
Content-Type: application/json
Content-Length: 2480
ETag: "9b2cf535f27731c974343645a3985328"
Last-Modified: Tue, 26 May 2026 10:30:00 GMT
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0

A GET request to the same URL returns the object body with the same cache-control posture. Treat the URL as an authenticated Console route, not as a public object-storage URL. Do not use it outside a signed-in Console session.

Status codes

Security notes

Private file access is separate from public branding and asset-document URLs. The Platform API requires an authenticated session and enforces object-key scope before reading storage.

The Platform API sets Cache-Control: no-cache, no-store, must-revalidate, Pragma: no-cache, and Expires: 0 on private file responses. Do not persist private file contents in shared caches. Store downloaded files only where your organisation's retention and access policy allows it.

A successful private file read proves only that the signed-in user can read the stored object at that key. It does not prove that a participant is approved, that an asset transfer is compliant, or that a document meets a regulator's evidence requirements.

Related pages

• KYC document uploads for the upload and confirmation workflow that stores KYC evidence.
• Token documents for asset document metadata and download behaviour.
• Request headers for API context headers used by integration clients.
• Error handling for production retry and recovery patterns.