File identity
A file is an object with an identity, not a reference to a place
What it gives you
Product entities and every internal reference store file_id, and version_id where a specific version matters. A read link lives for minutes and is issued again on every request. That is why moving between clusters, changing the storage location or adding a version breaks no reference anywhere in the products.
How it works
- file_id stays the same for the whole life of the object, the storage location changes in a separate field
- Region and storage_ref describe the place, the identity does not depend on it
- A download link is signed and lives exactly as long as the action it was issued for
- When a link expires the interface quietly asks for a fresh one instead of showing an error
Limitations
- A download link cannot be stored in a product forever: it expires, so products store file_id
- An object lives entirely in one storage region, versions of one file are never spread across regions
Which plan includes it
Platform
The feature is included in this plan and in every plan above it.
Compare plansFrequently asked questions
What happens to links in products if a file moves to another cluster?
Nothing. Products store file_id, not an address. The storage location is described by separate fields of the object and changes without touching the identifier, so every binding and link keeps working.
Why does a download link live for such a short time?
The link lifetime equals the window in which revoking access does not yet apply. A link that ends up in the wrong hands quickly becomes useless. When it expires, the interface requests a new link without the user noticing.
Can I refer to a specific version of a file?
Yes. Next to file_id you can store version_id when the entity needs exactly that version, for example a signed one. Without it the current version is returned.
