File Upload with API Keys

For server-to-server uploads, OAuth is the wrong shape. OAuth assumes a human at a browser: redirects, consent screens, scopes, a registered callback URL, and short-lived access tokens you have to refresh with a refresh token you have to store and rotate. None of that helps a cron job pushing a backup or a CI step uploading a build artifact — it just adds moving parts that fail at 3am. files.link uses long-lived API keys instead: create one in the dashboard, put it in an environment variable, and send it on every request. That's the whole auth model.

The mechanics are deliberately boring. The key goes in the Authorization header as its raw value — no Bearer prefix, no signing, no timestamp, no HMAC. Every call in the upload flow that talks to the API carries the same header: Authorization: $FILESLINK_KEY on the POST /v1/files/{folderId} that returns your presigned url and id, and again on the POST /v1/files/confirm-upload.

(The middle PUT to the presigned URL needs no header at all — the signature baked into that URL is its own authorization.) There's nothing to refresh, so a process can run for months without re-authenticating.

Mint a separate key per environment or per application — dev, staging, prod, or one per service — so you can reason about and rotate them independently. If a key leaks, revoke it from the dashboard and every request using it starts returning 401 immediately; generate a replacement, update the one env var, done. No coordinated client-secret rotation, no token-endpoint outage, no cascade across services that happened to share a credential.

Compared to cloud IAM — AWS access keys, signature v4, roles, and policy documents — there's no per-request signing to get wrong and no JSON policy to debug. Compared to OAuth, there's no callback to host and no token to keep alive. It's a single secret, one header, and a revoke button: the right ergonomics for machines uploading files.