Encryption

How Spun encrypts your data

Honest, scenario-by-scenario detail on what is end-to-end encrypted, what is only encrypted in transit, and what must be readable by Spun for the product to work.

At a glance

Encryption by scenario

Below is every type of data Spun touches and exactly how it is protected. We mark E2EE as Yes only when no Spun system can read the content.

Scenario	In transit	At rest	E2EE	Notes
1:1 voice call (Spun → Spun) DTLS-SRTP (WebRTC)	DTLS-SRTP (WebRTC)	Not stored	Yes	Pure peer-to-peer WebRTC. Keys negotiated between the two endpoints — Spun never holds them.
1:1 video call (Spun → Spun) DTLS-SRTP (WebRTC)	DTLS-SRTP (WebRTC)	Not stored	Yes	Same as voice. TURN relays only see encrypted packets when direct P2P fails.
Group call (3+ participants) TLS 1.2+ to SFU, DTLS-SRTP for media	TLS 1.2+ to SFU, DTLS-SRTP for media	Recording optional, stored in Cloudflare R2	No	LiveKit Cloud SFU decrypts media to route it to other participants. Standard SFU architecture.
Translation room (P2P mode, ≤2 participants) DTLS-SRTP (WebRTC)	DTLS-SRTP (WebRTC)	Translations stored only if recording enabled	Yes	Falls back to SFU if a third participant joins — see row above.
Translation room (SFU mode, 3+ participants) TLS 1.2+ to SFU	TLS 1.2+ to SFU	Translations stored only if recording enabled	No	LiveKit SFU has access to media to translate and re-mix.
WhatsApp messages (inside WhatsApp) Signal Protocol (Meta)	Signal Protocol (Meta)	WhatsApp's servers	Partial	WhatsApp itself is E2EE between participants. But once your gateway provider receives your inbound messages on your behalf, the gateway and Spun see plaintext — that is how the inbox works.
WhatsApp messages (in Spun) TLS 1.2+	TLS 1.2+	PostgreSQL on Hetzner, RLS-isolated per org	No	Necessary for inbox display, search, AI features, automations.
Spun Chat & team messages TLS 1.2+	TLS 1.2+	PostgreSQL, RLS-isolated	No	Plaintext at rest so messages are searchable and processable by AI features you enable.
Media attachments (images, video, docs) TLS 1.2+ (Cloudflare R2 + S3 SigV4)	TLS 1.2+ (Cloudflare R2 + S3 SigV4)	Cloudflare R2, AES-256 at rest by R2	No	R2 manages keys. Spun signs short-lived URLs to gate access per org.
Payment card data TLS 1.2+ direct to Stripe	TLS 1.2+ direct to Stripe	Never touches Spun	Partial	Stripe Elements collects card data directly in the browser — it never hits Spun's servers. We only receive an opaque customer ID.
AI prompts & outputs TLS 1.2+ to AI provider	TLS 1.2+ to AI provider	Optional logging (admin toggle)	No	Sent over TLS to OpenAI / AssemblyAI / etc. PII redaction (when enabled) strips sensitive fields before transmit.
Database backups TLS 1.2+	TLS 1.2+	Hetzner / Cloudflare R2, AES-256 at rest	No	Standard managed-backup encryption.

E2EE = end-to-end encrypted. "Yes" means even Spun cannot read the data. "Partial" means E2EE inside a third party (Stripe, WhatsApp) but visible to Spun for the portion we handle.

In transit

Everything that moves between your browser, our servers, and our sub-processors is TLS-encrypted.

TLS 1.2+ everywhere on the wire

All browser ↔ Spun, Spun ↔ WhatsApp gateway, Spun ↔ OpenAI / AssemblyAI / Deepgram / Sarvam / Azure, Spun ↔ Stripe traffic is TLS-encrypted. Older protocol versions are disabled at the load balancer.

Cloudflare-fronted edge

Cloudflare terminates TLS at the edge and re-encrypts to origin. Origin certificates pin requests to our Hetzner servers. WAF and DDoS protection are always on.

Short-lived signed URLs

Media downloads use S3 SigV4 presigned URLs scoped to a specific object and expire within minutes. Even a leaked URL stops working quickly.

At rest

Stored data is encrypted by the cloud provider and isolated per-organization by PostgreSQL row-level security.

PostgreSQL with row-level security

Every table holding tenant data has PostgreSQL row-level security (RLS) policies enforcing org isolation. Even a query mistakenly missing an org filter is denied at the DB level.

Single EU data tier

All application servers, PostgreSQL, and Redis run in Hetzner Nuremberg (Germany, EU). One data tier, one jurisdiction. AES-256 encrypted disks at rest.

Cloudflare R2 for media

Images, videos, audio, documents stored in Cloudflare R2 with server-side AES-256 encryption. Access gated by per-org, per-object signed URLs.

Voice & video calls

What's true E2EE, what's not, and why. We don't market group calls as end-to-end encrypted because they aren't.

1:1 voice & video — true E2EE

When two Spun users call each other, the audio and video are encrypted with DTLS-SRTP end-to-end between the two browsers. Spun's server only relays the SDP signaling. Even if Cloudflare TURN has to relay (symmetric NATs, firewalls), it sees only encrypted packets.

Group calls (3+) — encrypted in transit, not E2EE

Group audio/video calls and multi-party translation rooms use LiveKit Cloud as an SFU (selective forwarding unit). Media is encrypted with DTLS-SRTP between each client and the SFU, but the SFU decrypts on receipt to route to other participants. This is standard SFU architecture and is not end-to-end encrypted.

Translation rooms — P2P-first when possible

Translation rooms try P2P (E2EE) first when only two participants are present, falling back to the SFU when a third joins or when devices are too constrained for P2P. The connection mode is visible in the call UI.

Why we don't claim full E2EE on group calls

LiveKit supports an opt-in end-to-end encryption mode (using the Encoded Insertable Streams API) that protects media even from the SFU. It is not currently enabled on Spun group calls — adding it requires a key-exchange mechanism between participants and verified browser/codec compatibility for every supported client.

If full-group E2EE is a requirement for you, contact us at [email protected] — it is on the roadmap and we will share status.

Payments & identity

The most sensitive data is handled by specialized processors so Spun never sees or stores it.

Card data goes directly to Stripe

Stripe Elements collects card numbers, CVCs, and expiry dates inside an iframe that posts directly to Stripe — bypassing Spun's servers entirely. We only receive an opaque customer/payment-method ID. Stripe is PCI-DSS Level 1 certified.

Passwords are Argon2-hashed

Email/password accounts use Argon2id with per-user salts. We don't hold or log plaintext passwords. Google Sign-In delegates auth to Google entirely — no password ever exists in Spun for those accounts.

API keys and webhooks signed

All third-party webhook payloads (WhatsApp, Stripe, extension webhooks) are HMAC-SHA256 signed and verified server-side. Extension API tokens are short-lived JWTs (RS256) with a published JWKS endpoint.

WhatsApp messages: limits of E2EE

WhatsApp's E2EE protects messages while they're inside WhatsApp's infrastructure. The moment your gateway provider receives a message on your behalf, the gateway sees plaintext. This is true of every WhatsApp Business API provider — it's how business inboxes work.