Client File Upload Portal — Collect and Deliver Client Files

Client work is a file round trip. You send files to clients — proofs, drafts, reports, final deliverables — and you need documents back from them before you can do the work at all. Most teams run that round trip across three tools that don't talk to each other: an email thread for the small stuff, a WeTransfer link that dies in seven days, and a shared drive nobody outside the company can open without an account request.

The dedicated fix has historically been client portal software — ShareFile, FileInvite, Huddle and friends — which does solve the workflow but bills per user seat, wraps everything in a product your clients have to learn, and still leaves your files somewhere you can't address programmatically. files.link takes the other route: it gives you the storage, the client-facing links, and the API, and lets the portal be as thin as your engagement actually needs.

Here is what that looks like in practice. Each client gets a project, and each engagement gets folders inside it. Publish a shareable folder link and your client opens one URL in a browser, sees the files you've put there, and downloads them — no account, no invite, no password reset email on a Friday afternoon. Anything sensitive stays private instead: a private file has no public URL at all, and you hand out a signed link that expires (10 minutes by default, up to 7 days), or a permalink whose address never changes while the signed URL underneath is minted fresh on every hit, so it can't be forwarded or hotlinked forever.

Files your client can hold onto indefinitely get a permanent CDN URL that survives renames and folder reorganizations. Delivery runs over the same global CDN as the rest of the platform, which is the difference between a 900 MB video pack downloading at edge speed and it trickling out of one origin.

The intake side deserves a straight answer, because a portal page that overpromises collection is the fastest way to waste your afternoon. files.link does not host a public, no-account upload form today — there is no client document upload link a stranger can post files into. What exists is two real paths. Invite the client as a project collaborator with an editor role and they upload directly into the shared folder from the dashboard; that fits ongoing retainers, embedded contractors, and anyone you'd give a login anyway.

Or build the intake into a form you already control — your own client portal, your intake page, your internal tool — with the three-call REST upload described in the file upload API and the upload a file guide. That path is how agencies and product teams put a branded upload box on their own domain and still land the bytes in an organized files.link folder.

If you only need the intake half, file request links covers it directly.

Pricing is where the per-seat model usually stops making sense for client work. Portal products charge for every internal user and often every external one, so a busy quarter with a dozen clients costs the same as a quiet one and adding a freelancer costs a seat. files.link is prepaid credits against actual storage and bandwidth: an intense delivery month costs more, a quiet month costs less, nothing auto-renews, and there is no per-seat line.

Collaborators don't add a subscription tier. One honest limit worth stating up front: files.link is developer-first storage and delivery infrastructure, not a compliance product — it has no e-signature, no audit-trail export, and no regulatory certification program, so if your engagement is contractually bound to a specific compliance regime, verify that against your own obligations before moving client documents here.

For agencies, consultancies, studios, and product teams whose real requirement is "secure client file sharing that doesn't rot and doesn't bill by the head," this is the shape that fits.