Skip to main content
Encryption is the technical floor of any privacy posture. Rivet uses it in three layers — in transit, at rest, and on your device — and each layer is specific to the channel. Honest encryption claims are load-bearing in mental health, so what follows is exact about what’s covered, and equally exact about what isn’t.

​
In transit

Every connection between your devices and Rivet’s servers, and between Rivet’s servers and its sub-processors, uses HTTPS over TLS 1.2 or higher.
  • The web app at next.getrivet.ca is HTTPS-only. The browser refuses to connect over plain HTTP.
  • HTTP Strict Transport Security (HSTS) is set on every Rivet domain so a browser never falls back to an unencrypted connection.
  • The mobile app’s network calls to Rivet’s APIs are HTTPS-only.
  • API calls from Rivet’s worker to Supabase, Twilio, and Stripe are HTTPS-only.
  • Webhook calls from Twilio and Stripe back to Rivet are HTTPS-only, with signature validation (HMAC-SHA1 for Twilio, HMAC-SHA256 for Stripe) so Rivet can verify the call came from the right place.

​
At rest

The information Rivet holds about your practice and your clients is encrypted on disk:
LayerWhat’s encryptedHow
DatabaseEvery row in every tableSupabase platform-managed AES-256 disk encryption
Mobile session tokenYour signed-in session on your phoneiOS Keychain (Secure Enclave) on iOS; Android Keystore (TEE-backed) on Android
Web sessionYour signed-in session in the browserStored in the browser’s local storage; the connection between your browser and Rivet is HTTPS-only
Voicemail audio (Twilio storage)The 30-day platform retention copy held by TwilioTwilio’s platform-managed encryption
Audit logThe append-only event log Rivet writesSame platform AES-256 encryption as the rest of the database
Mobile sessions never end up in plaintext storage. If your phone is lost or stolen, the session is protected by your device’s lock screen and by the biometric unlock you’ve set up in the Rivet app — see security best practices for practitioners.

​
Video sessions — WebRTC DTLS-SRTP

When you and a client are in a Rivet video session, the audio and video streams travel directly between your devices using WebRTC with DTLS-SRTP encryption. That’s the same encryption pattern your phone uses for FaceTime or your browser uses for Google Meet.
  • Audio and video are encrypted at the source (your microphone and camera) and decrypted only at the destination (your client’s screen and speakers).
  • The signaling that sets up the connection — telling each side where to find the other — runs through Rivet’s servers over HTTPS. The media itself does not.
  • When a direct peer-to-peer connection isn’t possible (some corporate firewalls block it), encrypted media is relayed through Metered.ca’s TURN servers in Canada. The TURN relay cannot decrypt the media — it forwards encrypted packets and that’s all.
  • Sessions are not recorded. The architecture has no recording path.
The architecture choice — peer-to-peer DTLS-SRTP, no recording — is why video is the most strongly protected channel in Rivet.

​
What encryption Rivet does not claim

Honesty here matters as much as anywhere in the product.
  • SMS and voicemail audio at the carrier layer are not encrypted. The cellular network and the public phone system are inherently unencrypted. Rivet can’t encrypt the carrier last mile and doesn’t claim to. Inside Rivet’s systems, voicemail audio and SMS metadata are encrypted at rest and in transit — but the carrier leg between the caller’s phone and Twilio’s network is what it is.
  • In-app messages and voicemail transcripts are encrypted at rest and in transit, but Rivet’s servers can read them to deliver the service to you. Rivet doesn’t claim end-to-end encryption of message or voicemail content.
  • End-to-end encryption applies to video sessions specifically — between the two participating browsers / apps. It’s not a claim that applies to the inbox or the conversation history.

​
How this maps to the channels you use

ChannelEncryption posture
Phone call (PSTN to your Rivet number)Carrier unencrypted; Rivet’s handling encrypted
Voicemail audioCarrier unencrypted; Twilio storage encrypted; Rivet’s processing local in Canada
Voicemail transcriptEncrypted in transit (HTTPS); encrypted at rest (AES-256 on the database)
SMS to your Rivet numberCarrier unencrypted; Rivet’s storage encrypted at rest and in transit
Web app sessionHTTPS in transit; browser local storage at rest
Mobile app sessionHTTPS in transit; Keychain / Keystore at rest; biometric-locked on device
Video sessionWebRTC DTLS-SRTP, peer-to-peer; relay (when used) carries encrypted media only
Push notification payloadHTTPS to Apple / Google push services; carries an identifier, not transcript content

​
Practical implication

Inbound SMS and voicemail aren’t a place for clinical detail — not because Rivet handles them carelessly inside its systems, but because the carrier last mile is inherently insecure. That’s why Rivet auto-replies are written for triage and scheduling, not for clinical exchange, and why the channel-security position is that clinical conversation belongs in a video session.

Voicemail processing in Canada

Where the audio actually gets transcribed.

Audit logging

What Rivet records about access to encrypted data.

Security best practices for practitioners

The handful of habits that close the loop on the device side.