Photo delivery and client galleries
A shoot is 800 files and 40 GB. The client clicks once, gets one link, and can pick it up again tomorrow on hotel wifi — no “your download is being prepared” email.
Send a list of URLs. Your users get one download link — however many files, however large.
20 GB free every month. No credit card.
Integration
No SDK and no client library. One POST from the server code you already have, and a signed link you hand to your user.
curl https://api.eazip.io/jobs \
-H "X-API-Key: $EAZIP_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "files": [
{ "url": "https://…/report.pdf" },
{ "url": "https://…/photos.zip" }
] }'{ "success": true, "job_id": "550e8400-e29b-41d4-a716-446655440000" }curl https://api.eazip.io/jobs/550e8400-e29b-41d4-a716-446655440000 \
-H "X-API-Key: $EAZIP_API_KEY"{ "job": { "status": "completed",
"download_url": "https://api.eazip.io/download/eyJ…",
"expires_at": "2026-09-03T10:00:00Z" } }Rather not poll? Point a webhook at your endpoint instead.Server API quickstart →Webhooks →
What you stop building
Every team that ships a bulk download rebuilds the same six things, then maintains them.
A shoot is 800 files and 40 GB. The client clicks once, gets one link, and can pick it up again tomorrow on hotel wifi — no “your download is being prepared” email.
Attachment bundles, invoice exports, audit archives. The request every B2B customer eventually files, without a queue and a cleanup cron in your app.
The team selects 400 RAW files across folders and gets one archive. Zero egress on delivery is what makes the math work at that size.
ZIP64 by default
Multi-archive splitting with your chosen split size
Stored and stream modes
Explicit filenames and guaranteed order
Expiring signed URLs
Interrupted downloads pick up where they left off
No egress fees
Per-plan retention windows
Completion and failure webhooks
Dashboard with job history
Per-file error detail
Automatic cleanup
Origin and source-host allowlists
Publishable keys safe for frontends
Hard quota caps
Optional overage — disable it to cap your bill
Built in production
Eazip started as the export layer for our own file-sharing service and still carries that traffic every day. The engine has been zipping real customer archives since long before this page existed.
Pricing
Free is hard-capped: no card, no invoice. On paid plans, switch overage off and the bill stops at the subscription price.
Evaluate the API end to end.
Your first production export.
Export is a core workflow.
High volume, large archives.
Pay-as-you-go on paid plans: stream $0.004/GB · stored $0.002/GB-day — optional. Switch it off and jobs stop at the quota instead.
Public Apps can cap size per session — so a publishable key in your frontend has a provable billing ceiling.
More volume, custom retention, or an SLA? support@eazip.io or ping us on Discord.
Stream builds the ZIP while the user downloads it and keeps no archive. Stored builds the archive once, retains it for your plan window, and is better when the same ZIP may be downloaded more than once.
The job is blocked. Free accounts are hard-capped: no overage, no card on file, and no invoice. Paid plans can also disable overage to cap the bill at the subscription price.
Yes. Browser integrations use a publishable key scoped by a Public App. It restricts allowed origins, source hosts, delivery modes, file counts, and job size. Secret API keys stay on your server.
Yes. Short-lived presigned URLs are the recommended way to let Eazip read private objects without exposing bucket credentials.
When the archive fits comfortably in a browser tab and every source already sends CORS headers, the SDK can zip it locally in the user’s browser. Cloud takes over when the job is too large for a tab, too slow to hold a page open, needs to survive a reload, or has to be downloaded again later.
20 GB/mo free · no credit card · hard-capped.
Just want to try the open-source SDK first?npm i @eazip/react · Eazip.js