File Upload API

A file upload API should do one thing well: take bytes and give back a link you can use immediately. That is the whole flow here, and it is three REST calls with no SDK to install. Unlike a free anonymous pastebin, files.link is predictable paid storage — you authenticate with an API key, files persist until you delete them, and every public file is served over a global CDN — so it fits a product you are actually shipping rather than a throwaway drop.

Step one, POST /v1/files/{folderId} with the file's metadata, returns { success, urls: [{ url, id }] } — a presigned PUT URL and a file id. Step two, PUT the raw bytes straight to that url; they never stream through your API process, which matters when a user uploads a 200 MB file. Step three, POST /v1/files/confirm-upload with { ids: [id] } finalizes it, and the file is live at a permanent CDN URL worldwide.

The Authorization header is your raw API key — no Bearer prefix, no request signing. A Node.js backend tying the three calls together:

// Node 18+: three calls, no SDK. FL_KEY is your raw API key.
const api = 'https://api.files.link/v1';
async function uploadFile(bytes, name) {
  const step1 = await fetch(`${api}/files/${FOLDER_ID}`, {
    method: 'POST',
    headers: { Authorization: FL_KEY, 'Content-Type': 'application/json' },
    body: JSON.stringify({ filesMetadata: [{ name }] }),
  }).then((r) => r.json());
  const { url, id } = step1.urls[0];
  await fetch(url, { method: 'PUT', body: bytes });          // straight to storage
  await fetch(`${api}/files/confirm-upload`, {
    method: 'POST',
    headers: { Authorization: FL_KEY, 'Content-Type': 'application/json' },
    body: JSON.stringify({ ids: [id] }),
  });
  return id;                                                 // now has a CDN URL
}

For a React or browser upload, keep the two key-bearing calls on your backend and expose only the presigned PUT to the client, so a large file skips your server entirely and your API key never reaches the browser:

// your backend returns { url, id } from step 1; the browser does only the PUT
async function upload(file, presignedUrl) {
  await fetch(presignedUrl, {
    method: 'PUT',
    headers: { 'Content-Type': file.type },
    body: file,
  });
}

Temporary and private where you need it: send private: true with the metadata and no public URL is minted; when an authorized user asks for the file, your backend mints a signed URL that expires in ten minutes, so the links you hand out are short-lived rather than permanent. Public files instead get a stable direct URL served from 450+ edge locations — the same URL works in an <img> tag, a download button, or a webhook payload.

On limits and price, be clear-eyed: this is prepaid credits, not a free tier. Storage, CDN delivery, and API requests all draw from one balance, auto-recharge keeps you topped up, and you control retention by deleting files you no longer need. Compared with file.io's delete-after-download drops or TempFile.org's anonymous free hosting, files.link trades throwaway anonymity for a predictable, key-authenticated API you can build a product on — direct links, CDN delivery, and signed private access included.

Building the frontend or a specific stack? See the Node.js, React, and Next.js guides.

Came here looking for a file uploader or a file upload widget? Set expectations first: files.link is the upload API and the storage behind it, not a drop-in widget. There is no script tag to embed and no vendor component in your bundle — you build the uploader UI yourself (a native <input type="file">, a dropzone, or your framework's form handling) and point it at the three calls above.

What you get underneath is the part a widget usually wraps: direct file links that stay valid until you delete the file, and CDN-backed uploads live at 450+ edge locations the moment confirm-upload returns. If you are weighing that against a widget-plus-transformations product, the trade is spelled out in the Uploadcare alternative and Filestack alternative comparisons.