Privacy by architecture

The lifetime of a file, in both modes

There are exactly two ways a file moves through the API, and each has a precise, documented end of life:

In neither mode is a file ever written to disk. There is no storage tier, no object bucket, no temp directory: the result store is memory-backed and the machines run without swap, so there is no path from your file to a persistent medium.

Waiting results we cannot read

An async result has to wait somewhere until you collect it. The interesting question is who can read it while it waits. Here, nobody can, including us:

1. Two identities per job. Submission returns a public job id (safe in URLs, logs and webhooks) and a secret job key, shown exactly once. We store only a SHA-256 hash of the key, so it cannot be recovered from our side afterwards.
2. Encryption with your key. The waiting result is sealed with AES-256-GCM under a key derived from your job key. While it waits, our server holds ciphertext and a hash, and neither can produce your file.
3. Secrets never enter logs. The job key travels only in the X-Job-Key request header, never in a URL. Access logs record paths, so the key has no route into them, ours or any intermediary's.

Webhooks with nothing to leak

A webhook is your data crossing the network to a URL you chose, so it is designed to be worthless to everyone except you:

• No file content, ever. The payload carries the public job id, status and output metadata. The file itself only moves when you fetch it with your API key and job key.
• No secrets, ever. Neither your API key nor your job key appears in a delivery. An eavesdropper, a misconfigured proxy or your own request logger learns only that a job with an opaque id finished.
• Authenticated and replay-protected. Every delivery is HMAC-SHA256 signed with a key derived from your job key, with a timestamp for freshness and a stable event_id for deduplication. The scheme is published with a test vector so you can prove your verifier is correct before going live.
• Strict destination rules. Webhook URLs must be public https endpoints; private, internal and non-standard-port destinations are refused at submission time.

The full delivery format, receiver examples and retry semantics live in the webhooks guide.

What gets logged, and what never does

Operational logs exist so we can keep the service healthy. For conversion traffic they record the request path, status code, timing and a coarse outcome reason. They never contain:

• File contents, in any form, at any stage.
• Filenames. They travel inside the request body, which is not logged.
• Job keys or API keys. Secrets travel in headers and bodies, never in URLs, by design.
• Third-party log processors or analytics on conversion traffic. Operational logs stay on our infrastructure.

Your files are never used for training, never shared, and never inspected beyond the automated validation that keeps malformed uploads out.

A default, not a setting

Many conversion services store results on disk by default and offer a no-storage option you have to find, enable and trust on every request. That model leaves room for a missed flag, a misread default, or a retention policy you discover later.

PrivConvert has no such option because it has no such mode. There is no parameter that turns storage on, no plan tier that adds retention, and no configuration in which your file outlives the windows described above. The privacy model is the architecture, which also means it cannot regress quietly: a storage feature would have to be built, announced and documented before it could exist.