Designing a zero-retention media API

Most media APIs quietly become storage products: you send a file, it lands in a bucket, and its lifecycle becomes your problem — and the provider's liability. For privacy tooling that's backwards. If the product's promise is 'we remove identifying data', the API should hold that data for as close to zero time as physics allows.

The contract

MetaMarshal's API promise is three rules. Process in memory: synchronous requests never write the file to durable storage; it's parsed in a stream and the response is computed on the fly. Delete on a short TTL: batch outputs, which must exist somewhere while you fetch them, live in transient storage that auto-deletes after one hour. Never log content: request logs carry counts, sizes and timestamps for billing — never bytes, never metadata values.

Signed URLs as an expiry mechanism

Batch results come back as a manifest of signed download URLs. The signature encodes an expiry, and the expiry matches the storage TTL — so the link dying and the file being deleted are the same event. Nothing to revoke, nothing to remember. The clock enforces the policy.

Why not just promise deletion?

Policies drift; architectures don't. If files land in long-lived storage, deletion depends on a cron job someone maintains and an audit nobody runs. If the storage is transient by construction — tmp directories with lifecycle rules, or GCS objects with TTL — retention isn't a discipline problem anymore. Zero-retention should be something the system can't get wrong.

The consumer app goes further

The browser app never sends the file anywhere at all — parsing and scrubbing run client-side. The API exists because bulk workflows genuinely need servers. Two trust models, one honest line each: 'nothing leaves your device' and 'we process and forget'.