Introduction
LucidLink version 3.7.8703 introduces support for HTTP file linking. This allows external files to be linked within the filespace by supplying a URL as part of the link request. These are called "HTTP Link Files" to distinguish them from the "Single Object Files" used in conjunction with LucidLink-managed data stores.
Because many providers offer a custom API with an HTTP-based method for accessing files (even those who do not directly expose S3), this feature makes possible a wide assortment of integrations with new tools and storage platforms.
Examples
- Google Drive
- OneDrive
- Dropbox
- Box
- Frame.io
- and many more
HTTP file linking also supports providing pre-signed URLs generated by S3-compatible storages as an alternative to LucidLink-managed data stores and external entries.
No Data Store Required
Unlike SingleObjectFile entries, HTTP file entries do not use a Data Store. There is no LucidLink-managed credential store authenticating or refreshing URLs on your behalf.
This means:
- You do not need to create or configure a Data Store to link HTTP files.
- LucidLink does not manage authentication or receive credentials - the user or automation is responsible for authenticating with external providers and supplying the asset URL for linking.
- LucidLink will not automatically renew, re-sign, or otherwise maintain the accessibility of HTTP file URLs (which depending on provider generally expire within a few days maximum).
- If a URL expires or becomes inaccessible, the linked file will be unreadable until updated via
PATCHwith a valid URL. - LucidLink cannot see or access the content.
High-level Diagram
HTTP File Linking - API Reference (version 1.4.3 and up)
A new external entry kind, HttpLinkFile, can be used with the existing External Entries endpoints:
| Method | Endpoint | Description |
|---|---|---|
| POST | /filespaces/:filespaceId/external/entries |
Create an HTTP file entry |
| PATCH | /filespaces/:filespaceId/external/entries/:entryId |
Update the URL of an existing HTTP file entry |
| DELETE | /filespaces/:filespaceId/external/entries/:entryId |
Remove an external entry |
Creating an HTTP file entry:
POST /filespaces/:filespaceId/external/entries
{
"path": "/reports/dataset.csv",
"kind": "HttpLinkFile",
"httpFileParams": {
"url": "https://example.com/data/dataset.csv"
}
}-
path— the absolute path where the file will appear in your filespace. -
kind— set to"HttpLinkFile"(as opposed to"SingleObjectFile"for S3-backed entries). -
httpFileParams.url— the HTTP or HTTPS URL of the file. Must include the protocol (http://orhttps://).
Updating an HTTP File URL
To change the URL backing an existing HTTP file entry, send a PATCH request with the entry ID and the new URL:
PATCH /filespaces/:filespaceId/external/entries/:entryId
{
"httpFileParams": {
"url": "https://example.com/data/dataset-v2.csv"
}
}The entryId is returned in the response when the entry is first created via POST. Only entries with kind HttpLinkFile can be updated this way. No dataStoreId or kind field is required on the update — just the new httpFileParams.url.
This is particularly useful for rotating pre-signed or time-limited URLs before they expire.
URL Requirements
- The HTTP server hosting the file must return
Content-LengthandRangeheaders. - The URL should directly serve a static asset (such as a media file or document) and not a webpage that embeds these resources.
- While any URL that meets the
Content-LengthandRangeheader requirements should work, supplying the wrong type of link may result in unintended consequences (such as linking an .html file in the filespace). - Users of this feature should consult their providers' API documentation to ensure the correct type of URL is being used.
- Share links from popular platforms in particular can be expected to direct to a web portal that embeds the content rather than serving it directly.
- While any URL that meets the
Security
HTTP Link Files are a great fit for users with stringent security requirements because only a URL needs to be provided to link a file, and that URL is securely encrypted with keys that only the filespace owner and users possess in line with the filespace's permissions. LucidLink does not receive credentials for your storage or tools and does not control the lifecycle for the links provided - giving the customer complete control over what is shared, with whom, and for how long.