Uplint sits between your application and your object stores. It gives every file a durable identity, applies your routing policy, writes to the bucket you choose, and serves it back — through one API that doesn't change when your infrastructure does.
Each step is a service in the control plane. Your application only ever sees the first and the last.
Your application sends the file and names a storage target. Nothing about the provider is in the request.
POST /v1/filesUplint issues a durable file ID and records the metadata your app attached.
file_8Kx92mPolicy decides the provider, bucket, and region for this tenant or target.
india-data → S3 · MumbaiThe object lands in your bucket, under credentials you connected. Uplint keeps the reference.
company-filesDeliver through a signed URL, or move the object to another provider. The ID never changes.
/v1/files/:id/url · /moveSix services, one surface. Each one removes a piece of provider-specific code from your product.
Connect AWS S3, Azure Blob, Google Cloud Storage, Cloudflare R2, or any S3-compatible store. Uplint uses the credentials you provide, scoped to the buckets you choose.
Every object gets a stable ID and a metadata record. Your database, your URLs, and your product logic never point at a provider-specific path.
file_8Kx92minvoice.pdf · 283.9 KB · customer: cus_72mDeclare where files should live per customer, per region, or per storage target. Change the destination in configuration, not in code.
india-dataS3eu-residencyAZasia-primaryGCRequest a short-lived signed URL for any file ID. Uplint resolves the current location and signs against the right provider.
GET https://…/file_8Kx92m?sig=…&exp=300expires in 5 minMove an object between buckets or providers. The file ID stays the same; only the location record updates.
file_8Kx92mUploads, retrievals, moves, and deletes are recorded with the actor, the time, and the destination — one trail across every provider.
Five operations cover upload, retrieval, delivery, movement, and deletion. There is no provider-specific call to learn.
/v1/filesUpload a file into a storage target. The provider is decided by policy, not by the caller.
// multipart/form-datafile: invoice.pdfstorage: "production"metadata: { customer: "cus_72m" }{"id": "file_8Kx92m","storage": "production","location": { "provider": "s3", "bucket": "company-files", "region": "ap-south-1" },"size": 50536448,"content_type": "application/pdf","metadata": { "customer": "cus_72m" }}The control plane never becomes the place your data lives. It stays the layer that knows where it is.
Objects are written to storage you own. Uplint holds identity, metadata, and routing — not a copy of your files.
Each storage connection uses credentials you issue, limited to the buckets it needs. Revoke them at the provider and the connection stops.
Buckets stay private. Access to a file happens through signed URLs that expire, never through public object paths.
Uplint talks to every provider over TLS, and objects are encrypted at rest by the provider you chose.
No. Files are written to the bucket you connect, in your account. Uplint stores the file record — identity, metadata, and current location — and the routing configuration.
Yes. Routing policy decides the destination per tenant, region, or storage target, so one product can keep some customers on S3 and others on Azure or Google Cloud.
Nothing. A move updates the location record behind the ID. Every reference in your application keeps working.
AWS S3, Azure Blob Storage, Google Cloud Storage, Cloudflare R2, and any store that speaks the S3 API.
Connect a bucket, create an API key, and upload a file. The quickstart walks through it in five minutes.
Connect storage, create a key, and upload — the same call you'll still be making when your infrastructure looks nothing like it does today.