Files SDK and Cloud File Storage API

A "files SDK" usually means a vendor package you install, wire credentials into, and keep upgrading. files.link inverts that: the API is plain REST, so the SDK is either a few lines you paste into your own codebase or a fully typed client you generate from the OpenAPI spec — nothing to npm install, no version treadmill, no bundle weight in a Lambda.

The upload is three calls. First, POST /v1/files/{folderId} with your raw API key in the Authorization header (no Bearer prefix) and the file's metadata; the response is { success, urls: [{ url, id }] }, where url is a presigned PUT target. Second, PUT the raw bytes straight to that URL — they never stream through your own server, which matters when a user uploads a 200 MB file.

Third, POST /v1/files/confirm-upload with { ids: [id] } to finalize, and the file is live at a permanent CDN URL. Here is the whole client — this file is the SDK:

// files.link SDK — the entire thing. FL_KEY is your raw API key.
const api = 'https://api.files.link/v1';
const auth = { Authorization: FL_KEY, 'Content-Type': 'application/json' };

export const files = {
  async upload(bytes, name, { folderId = FOLDER_ID } = {}) {
    const { urls } = await fetch(`${api}/files/${folderId}`, {
      method: 'POST', headers: auth,
      body: JSON.stringify({ filesMetadata: [{ name }] }),
    }).then((r) => r.json());
    const { url, id } = urls[0];
    await fetch(url, { method: 'PUT', body: bytes });      // straight to storage
    await fetch(`${api}/files/confirm-upload`, {
      method: 'POST', headers: auth,
      body: JSON.stringify({ ids: [id] }),
    });
    return id;                                             // now has a CDN URL
  },
};

Prefer a typed client? The full OpenAPI 3.0 spec is published at api.files.link/api-docs.json with a hosted Swagger UI at api.files.link/api-docs — point openapi-generator at it and get a generated SDK in TypeScript, Python, Go, Java, or any language it supports, method signatures and response types included. Either way you are calling the same endpoints, so you can start with the paste-in wrapper and graduate to a generated client without changing the backend.

Delivery and access come from one flag, not two subsystems. Public files return a stable direct URL served from a global CDN — drop it in an <img> tag, a download button, or a webhook payload. Mark a file private: true at upload and no public URL is minted; when an authorized user needs it, your backend mints a signed URL that expires in ten minutes. For the delivery side in depth — how an upload becomes a globally cached URL with no distribution to configure — see file storage with CDN, and for the endpoint-by-endpoint API tour see the cloud file storage API.

On price, be clear-eyed: this is prepaid credits, not a free tier. Storage, CDN delivery, and API requests all draw from one balance with auto-recharge, so there is no separate egress meter to turn a traffic spike into a surprise invoice. Wiring this into a specific stack? The Node.js, React, and Next.js guides carry runnable snippets, and the file upload API page walks the same three calls from curl, fetch, and Node.