A WeTransfer Alternative for Apps

WeTransfer was built for one job: a designer drags a 200MB folder onto a page, types a client's email, and the link dies in seven days. That is genuinely good for one-off handoffs. It is the wrong shape for a product. The moment your app needs to accept an upload, store it, and serve the same URL to a thousand users next quarter, the WeTransfer model — short-lived links, an email-centric flow, no first-class developer API — stops fitting. cdn22.net is built for the permanent, programmatic case.

You upload through a three-call REST sequence (POST /v1/files/{folderId} to register the file and get a presigned PUT URL, PUT the bytes straight to storage, then POST /v1/files/confirm-upload with {ids:[...]}), and you get back a URL that stays live as long as your prepaid balance is funded. No 7-day timer, no 'this transfer has expired' page when a customer clicks an old link.

The two products diverge on three axes worth being honest about. First, expiry: WeTransfer expires by design; cdn22.net links are permanent unless you set an expiry yourself. Second, integration: WeTransfer's strength is the no-signup drag-and-drop web flow, which cdn22.net deliberately does not replicate — there is no anonymous one-off send here, every upload is authenticated with a raw API key.

Third, billing: WeTransfer sells seats and plan tiers; cdn22.net is prepaid credits that debit daily against actual storage and delivery, so a quiet month costs almost nothing and a busy one never trips a seat limit. A typical migration: if you were emailing clients WeTransfer links from a backend cron, swap the WeTransfer step for the three-call upload, store the returned file id and URL in your database, and email that URL instead.

It will never expire on you. If you genuinely only need to hand a single video to one client today and never touch it again, keep WeTransfer or reach for transfer.sh — cdn22.net is the better tool when the file is part of something you are building, not a disposable courier job. Files are served from a global CDN, so the same permanent link is fast whether the recipient is in Berlin or Singapore.

For a section-by-section breakdown of the two approaches, see cdn22.net vs WeTransfer.

The cleanest way to frame the choice is courier versus warehouse. A courier is right for one parcel: drag, type an email, done, and nobody needs an account. A warehouse with a delivery fleet earns its keep when the same asset ships again and again — the file stays in reusable storage, every send reuses one permanent CDN URL instead of a fresh upload, and your backend rather than a human at a browser decides who gets a link and for how long.

That is the whole split between consumer transfer tools and developer file delivery. For the same table run against the wider set of one-off senders — Filemail, pCloud Transfer, Wormhole, file.io — the large file transfer page covers them side by side.

Five workflows where the repeat-delivery shape is the deciding factor. Client asset delivery: a studio hands the same 4 GB master to a client, their editor, and their agency over several months from one link that never expires, and the client file upload portal covers the intake half of that loop. App-generated download links: a backend finishes a render, export, or invoice and calls the file transfer API to mint the URL it emails or shows in-product.

Expiring and private links: mark a file private and your server signs a link on demand, from 60 seconds up to 7 days — closer to WeTransfer's expiry model but under your control, with the mechanics on the temporary file hosting page. Ongoing team and customer sharing, covered on the file sharing page.

And plain app storage, where what you actually wanted was a Dropbox alternative for developers. Billing follows usage rather than seats: prepaid credits debit daily against stored bytes and delivered bandwidth, so a month with one big client push and a quiet month do not cost the same.