Gzip

Compression is everywhere, but rarely in your control

Most web stacks compress HTTP responses transparently, which is great for serving pages but useless the moment you need to compress a log file before archiving it, shrink a JSON export before storing it, or decompress an inbound webhook payload that arrived gzip-encoded from a third party. Those are file- and blob-level jobs, not response-level ones, and doing them inline in application code means burning CPU cycles that could be serving users instead.

Three algorithms, three trade-offs

POST /data/gzip takes an algorithm parameter — gzip, deflate or brotli — plus a direction of compress or decompress, and returns the result via task_id. Gzip is the ubiquitous choice, readable by essentially every tool since the 1990s; deflate is its raw core algorithm without the gzip wrapper, useful when a spec explicitly calls for it (like some ZIP internals or older HTTP implementations); brotli, developed and open-sourced more recently, generally compresses tighter than gzip at similar speed, which matters when you're optimizing storage costs or transfer size for large text-based payloads.

What determines the size you get back

Compression ratio depends entirely on the nature of your data: highly repetitive text like logs, CSV exports or minified JSON can shrink dramatically, while already-compressed formats such as JPEG or a previously-gzipped file will barely change size and may even grow slightly due to format overhead. The endpoint doesn't try to guess what's optimal for your content — you choose the algorithm, and the result tells you exactly what ratio you achieved.

Built for pipelines, not one-off downloads

Because every call is async with a task_id, you can fire off compression jobs from a queue worker, a scheduled export, or a webhook handler without blocking on the response, then pick up the compressed or decompressed file from a signed link or your own webhook receiver. A failed job — malformed input, an unreadable stream — costs you nothing, since we only bill successful completions after retries are exhausted.

Where this sits in a larger process

This endpoint pairs naturally with our archive and conversion tools: decompress an inbound gzip payload, hand the raw bytes to a format converter, then re-compress the output with brotli before storing it. Treat it as a utility block you drop into any pipeline that moves data between systems with different compression expectations, rather than a destination in itself.