Encryption and credentials

Data encryption

• In transit: TLS for all connections, to the app, the API and between our infrastructure providers.
• At rest: AES-256 across the database and storage.
• Integration credentials: encrypted again at the application layer with AES-256-GCM before they reach the database, on top of at rest encryption. A database read alone cannot recover a connection secret.

API keys

API keys are generated with cryptographic randomness, shown once and stored only as a hash computed with a server held secret. Kabaido cannot recover a lost key, and a database read alone cannot produce a usable one. Every key carries explicit scopes, can be revoked instantly and records when it was last used.

Webhook signing

Outbound webhooks are signed with HMAC SHA-256 over a timestamp and the exact raw body, keyed by a per endpoint secret shown once at creation. Verification examples in TypeScript and Python are on the webhooks page. Signatures are compared in constant time and carry a timestamp so receivers can reject replays.

Inbound credentials

Inbound endpoints use long random tokens as capabilities, with optional signature verification for senders that can set headers. Pausing or deleting an endpoint revokes its URL immediately.

Portal links

Quote portal links carry an unguessable token scoped to one quote. The portal exposes only that quote, offers no actions once the quote is decided or expired and is rate limited against scanning.

Connected inbox and calendar tokens

Connecting a Gmail or Microsoft 365 inbox, or a calendar, stores an OAuth token rather than a password, which means the grant is scoped to what the feature actually needs and can be withdrawn from the provider's own console as well as from Kabaido. Those tokens are encrypted at the application layer like any other integration credential, and disconnecting removes them.

Why application layer encryption on top of at rest

Encryption at rest protects the disk. It does nothing about a query. Anything that would let somebody hand you a working credential to a customer's ERP is worth a second layer, so integration secrets, API keys and connected account tokens are all encrypted or hashed by the application before they are written, and the key that reverses that lives outside the database.

Sign in

Accounts sign in with email and a password of at least 8 characters, a magic link or Google and Microsoft single sign on where enabled. Passwords are hashed by our authentication provider and never stored in plain text.

Sessions are held in httpOnly cookies rather than anywhere JavaScript on the page can read them, and every request from the browser is authorised again on the server. A signed-out session cannot be resurrected from a cached page.