Encryption and credentials
Know how data, keys and secrets are encrypted, hashed and verified end to end.
Updated 23 September 2026
- Why
- Encryption at rest protects the disk but does nothing about a query.
- How
- Secrets are encrypted or hashed by the application before they are written, with a key held outside the database.
What protects what
| Item | Protection |
|---|---|
| All traffic | TLS, to the app, the API and between providers. |
| Database and files | AES-256 at rest. |
| Integration credentials and connected inbox or calendar tokens | Encrypted again with AES-256-GCM before they are stored. A database read alone cannot recover one. |
| API keys | Shown once, stored only as a hash with a server held secret, scoped, revocable and stamped with their last use. |
| Outbound webhooks | Signed with HMAC SHA-256 over a timestamp and the raw body, with a per endpoint secret shown once. |
| Inbound endpoints | Long random tokens, with optional signature checks. Pausing or deleting revokes the URL at once. |
| Quote portal and document links | An unguessable token scoped to one record, rate limited against scanning. |
Verification examples for webhooks are on Webhooks. Connecting Gmail, Microsoft 365 or a calendar stores an OAuth grant, never a password, and disconnecting removes it.
Sign in
Accounts sign in with an email and password, or with Google or Microsoft where enabled. Passwords are hashed by the authentication provider. The session lives in a cookie and is checked again on the server for every request.