File Upload CLI

The honest version of 'file upload CLI' for files.link is that there isn't one to install — and that's the feature. The REST API is the contract, so curl (or wget, or httpie, or whatever HTTP client your image already has) *is* the CLI. No vendor binary to download, no Homebrew tap, no version to pin, no latest that breaks your pipeline when it auto-updates, no SDK that lags a language runtime. A clean Alpine container or a locked-down CI runner can upload a file with the tools it already ships.

Contrast that with reaching for the AWS CLI just to push an artifact somewhere: you're now installing a multi-hundred-MB toolchain, wiring up a credentials file or instance role, and learning a subcommand surface — a lot of ceremony for 'put this file at a URL.' Custom vendor CLIs trade one install problem for another: another binary in your base image, another thing to keep current, another failure mode in CI. files.link collapses all of that into three plain HTTP calls and a single API key in an environment variable.

The whole upload is three commands. First, POST /v1/files/{folderId} with Authorization: $FILESLINK_KEY and your file metadata; the response is { success, urls:[{ url, id }] }. Second, PUT the bytes straight to that presigned url with --upload-file. Third, POST /v1/files/confirm-upload with { "ids": ["<id>"] } to finalize. Pipe the first response through jq to capture url and id into shell variables and you can chain all three in a single copy-pasteable block.

Want something that feels like a CLI? Wrap those lines in a ~10-line shell function named flup and you have your own upload command with zero dependencies.

It works identically everywhere curl works, which is everywhere: Linux, macOS, and Windows 10+ all ship curl, so the same three commands run in bash, zsh, PowerShell, or cmd, inside Docker, GitHub Actions, GitLab CI, or a cron job — no per-platform install matrix to maintain.