Bulk Import Doesn't Encrypt Automatically. Here's the Opt-In Path That Does.

Enterprise customers ask for bulk import almost immediately after they ask for the API. The reason is obvious once you hear it: nobody wants to hand-create 8,000 links one at a time because their team is migrating off a spreadsheet, a legacy shortener, or a homegrown internal tool.

What’s less obvious is a limitation we have to be upfront about: bulk import happens server-side, and our encryption doesn’t.

Why this isn’t a small detail

Every link created through our actual product — the dashboard, the homepage playground — gets encrypted in the browser before the destination URL ever reaches us. That’s the whole zero-knowledge guarantee. A CSV upload to an API endpoint doesn’t have a browser in the loop. There’s no client-side JavaScript running against your spreadsheet to encrypt each row before it hits our server. So by default, links created through bulk import are stored as plaintext, the same way a traditional shortener would store them.

We’re not going to describe that as “basically the same” as our normal encryption model, because it isn’t. If you bulk import 8,000 links without doing anything else, those 8,000 destination URLs sit in our database in a form we can read. That’s a real, meaningful difference from every other link on the platform, and it deserves to be said plainly rather than smoothed over.

What we built instead of pretending otherwise

We added a real opt-in path: if you encrypt each destination URL yourself, using the same AES-256-GCM scheme documented in our Encryption Architecture Guide, and include the ciphertext and salt as columns in your import file, we’ll store it as genuine ciphertext — identical in every respect to a link created through the browser. The API now checks for this explicitly (encrypted: true plus a salt) instead of silently discarding the distinction.

This isn’t automatic, and we’re not going to imply it is. It requires the system doing your bulk import — your migration script, your internal tool — to run the encryption itself before the data reaches us. For most teams doing a one-time CSV migration, that’s more setup than they’ll want. For teams with an existing pipeline that can do the encryption step, it closes the gap completely.

The honest recommendation

If your links aren’t sensitive — marketing campaign URLs, public content, things you wouldn’t mind existing in plaintext somewhere — bulk import as-is is fine, and worrying about it is probably not the best use of your time. If what you’re migrating includes links you’d specifically chosen zero-knowledge encryption to protect, don’t assume bulk import gives you that by default. It doesn’t, unless you do the encryption step yourself. We’d rather you know that going in than discover it later.