Access control and visibility

How Storage decides who can read a file, using per-asset visibility, signed URLs, and automatic tenant scoping.

Storage keeps access simple: every asset is either public or private, and that single setting decides how it can be read. There are no per-user access lists to maintain on the delivery path.

Public assets

A public asset is served from the delivery host to anyone with the URL, no authentication required. This is what you want for catalog imagery, marketing assets, downloadable spec sheets, and 3D models on a storefront. Link to them directly and the edge serves them fast, cached across the EU.

Private assets

A private asset is not reachable by its plain delivery URL. It opens only through a signed URL, a link that carries time-limited authorization and stops working once it expires. Use private for invoices, contracts, customer uploads, and anything that shouldn't be guessable or permanently linkable.

Setting visibility

Set visibility when you upload by sending visibility=public or visibility=private. Change it later with a metadata update:

Bash
curl -X PATCH https://api.revenexx.com/v1/storage/assets/<ASSET_ID> \
  -H "X-Revenexx-Api-Key: <API_KEY>" \
  -H "X-Revenexx-Tenant: <TENANT_SLUG>" \
  -H "Content-Type: application/json" \
  -d '{ "visibility": "private" }'

Tenant scoping

Every management call carries X-Revenexx-Tenant, and Storage only ever returns and modifies files that belong to that tenant. Your data is automatically scoped to your tenant; one tenant can never see or touch another's files. You don't configure this and you can't turn it off.

The management API itself, uploading, listing, updating, deleting, signing, always requires valid credentials. Visibility only governs the public read path on the delivery host.

What's next

Was this page helpful?