Encrypted by default

Most API clients ask you to trust them with a lot: your API keys, your bearer tokens, your internal endpoint names, sometimes entire request bodies full of customer data. That trust is usually implicit — “we store your data securely” — and rarely explained further.

We’d rather not ask for that trust at all. So we designed ReqBox so the server structurally can’t read your workspace content, not just “won’t.”

What gets encrypted

Everything that lives inside a workspace: collection and folder names, request URLs, headers, bodies, auth configuration, notes, and — as of this month — environment and variable values across workspace, collection and environment scopes. All of it is encrypted on your device, before a single byte leaves it.

The backend only ever stores and routes ciphertext, plus the metadata it genuinely needs to function: object IDs, timestamps, roles, revision numbers. It has no way to decrypt request bodies or variable values, because it never holds the key that could.

Environment editor showing an API-KEY variable marked as Secret, its value masked as a row of dots

Mark a variable Secret and its value stays masked in the editor — not just hidden from view, encrypted before it’s ever saved.

How the keys work

Each workspace has its own symmetric encryption key, generated on a member’s device — never on our servers. When you invite someone to a workspace, an already-authorized device wraps that key for the new member’s identity key and sends only the wrapped copy. Our server relays it without ever being able to open it.

Under the hood:

XChaCha20-Poly1305 encrypts the actual content (collections, requests, variables, everything listed above).
Argon2id derives your account key from your password — the expensive-to-brute-force part.
HPKE over X25519 wraps a workspace key to a specific person’s device identity, so sharing a workspace doesn’t mean sharing a plaintext secret over the wire.

None of this is exotic. These are the same primitives you’d expect in any audited end-to-end encrypted system — we didn’t invent our own crypto, and we’re not going to.

What this means in practice

A few honest consequences, because a security model that only lists benefits isn’t a security model:

A brand-new member can’t see workspace content until an existing device is online to wrap the key for them. That’s the cost of not having a server-side master key.
Removing someone from a workspace doesn’t retroactively un-download what they already had. Key rotation stops future access; it can’t reach into a former member’s laptop.
Even inside a shared workspace, your own private data — currently, local/personal variables — is encrypted under a separate key that only your account can unwrap, so it’s not just filtered from other members by a database query. Even a fully compromised server can’t read it.

We think an API client that holds your credentials should be built this way as a baseline, not as a premium feature. It’s why “encrypted by default” is the first thing we lead with, not a line item in a security whitepaper nobody reads.