Skip to main content
VendaleVendale

Security

Money and messages move on verified rails.

Vendale sits between your messaging channels and your customer records. This page explains how that boundary is enforced in the same architecture that runs in production, without hand-waving.

01

Credentials never touch the client

Channel and payment credentials are encrypted at rest on the server. Each secret class has its own encryption key, and startup refuses to boot if two classes share key material.

Per-class key separation enforced at boot

02

Tokens are memory-only

The desktop app holds access tokens in memory and refresh tokens in an httpOnly cookie. Nothing sensitive is written to localStorage, sessionStorage, SQLite, or any file. Verified in the packaged runtime.

Verified in the packaged runtime

03

Webhooks are signed and idempotent

Every message and payment event is signature-verified over the raw body before parsing, checked in constant time, deduplicated, and processed exactly once with replay safety by construction.

Constant-time comparison, dedupe keys

04

Tenant isolation is total

Every record is scoped to its organization, and every query checks that boundary. Isolation tests run on every change.

Isolation tests run on every change

05

Everything is audited

The audit log is append-only and immutable: no update or delete routes exist. Customer, order, product, broadcast, ticket, and permission mutations all write structured audit events with actor and timestamp.

Append-only; no update/delete routes exist

06

Production boots fail-closed

Production rejects insecure default settings, refuses to enable live sends without explicit operator flags, and blocks dev seeds outside development. Safe defaults are enforced by the config layer itself.

Config layer refuses insecure defaults

The numbers behind the claims

Counted from the codebase, not from a deck.

1,000+

backend tests in the suite

97

permission keys, enforced in UI + API

5

system roles, least privilege by default

0

secrets in the desktop binary

How to verify each claim yourself

Artifact integrity

Every installer publishes its SHA-256 on the download page. Compute the hash of the file you downloaded and compare it with the published value. The release record is public.

/download → verify before you run

Behavioral claims

Memory-only tokens, append-only audit, and org-scoped queries are enforced in the application. The deployment kit includes a verification suite, but customer-hosted production use has not been validated.

/changelog → every fix, with its root cause

Verify the release and its current boundaries.

The deployment kit, backup scripts, and restore checks are available for technical review. No customer-owned production instance has been provisioned; confirm hosting and support scope before relying on it.

Request access