How long your file exists here, and how to check.

Direct requests

A request to /v1/compress, /v1/convert or /v1/strip-metadata is streamed to a processing engine. The engine writes the file to a private working folder, processes it, and streams the result back in the same response. When the response has been sent, the folder is deleted. The file is never written to storage and there is nothing left to retrieve.

Jobs

Larger files cannot be handled inside one request, so a job holds two files for a short time:

You can delete both immediately with DELETE /v1/jobs/{id}. If you give the job an output.url, the result is uploaded straight to your own storage and we hold no copy of it at all. An upload that is never used in a job is removed by a storage rule within a day.

Where processing happens

Files are processed in engine containers that have no outbound network access. Each job gets its own working folder. The engine identifies a file from its contents, refuses formats it does not handle, and enforces limits on pixels, pages, duration and running time before doing any real work.

What we log

For each request we record:

• the time, the account and the key that made it
• the operation and the kind of file (image, PDF, audio and so on)
• input and output sizes in bytes, and how long processing took
• whether it succeeded, the error code if not, and what it cost

We do not log file names, file contents, or anything derived from the contents. A job keeps the file name you gave it so the download has a sensible name; it is deleted with the job.

Receipts

Every finished job has a receipt at GET /v1/jobs/{id}/receipt. It states the SHA-256 of the input and the output, their sizes, and the times each was deleted, and it is signed with an Ed25519 key whose public half we publish. You can keep receipts as evidence of what was processed and when it was removed. How to verify one.

What we do not promise

• End-to-end encryption. Files are encrypted in transit and at rest, but the engine has to read a file to compress it.
• Content inspection. We do not look inside files. That means we do not vet them either; the acceptable use policy says what may be sent.
• A fixed processing location. Files are processed on Cloudflare's network. Storage and processing pinned to the EU is planned and not yet available.

Who else is involved

Three companies process data for the API: Cloudflare runs the infrastructure, Stripe takes payments, and Resend sends account email. Only Cloudflare ever handles your files. The sub-processor list has the details. Two advertising services, Meta and X, are told about account events, never about files: see the next section.

These pages

The developer pages, the documentation and the dashboard load no advertising pixels and no analytics scripts, set no Meta or X cookies, and send no page views to any advertising platform. The Smol for Mac marketing pages do use those, as described in the main privacy policy.

Two things do happen here, and we would rather say so plainly:

• We note how you arrived. When you come to one of these pages from another site, we record the page you came from, the page you landed on with any campaign tags or ad click identifier in its address, your IP address, country and browser type. A first-party cookie, _uid, holds a random visitor ID so that the note can be found again; no script can read it. This stays in our own database. We use it to learn which articles, searches and ads bring people to the API.
• We report three account events to Meta and X. We advertise on both, and to measure that we tell them when an account is created, when a checkout is started and when an invoice is paid. Meta receives a hashed copy of your email address, the visitor ID, any Meta click identifier, your IP address, browser type and approximate location, and for payments the plan and the amount. X receives a hashed copy of your email address, and for payments the plan and the amount. Sign-ups and checkouts are reported to X only if we have set up an event for them. The email address is hashed with SHA-256 before it leaves us and is never sent in readable form.

Your files, your API requests, your keys and your usage are never part of either. Nothing you send to api.smolmac.com with an API key is recorded for advertising, and the API itself sets no cookies.