Resources · Security & Trust

Lean on purpose.

One section we can actually stand behind today, rather than a resource centre with empty shelves. Everything below is implemented in the shipped product and described in enough detail for you to ask us a hard question about it.

What this page does not claim

No certifications, no compliance standards, no uptime figures, and no encryption-strength marketing. None of those have been independently audited, so none of them appear here. If a procurement checklist needs one, the honest answer today is that we do not have it — and you should expect a vendor to tell you that before you sign, not after.

The security model, stated plainly.

Each control below says what it protects and how it is implemented, because “enterprise-grade security” tells an evaluator nothing.

Strict multi-tenant isolation

Every record belongs to exactly one workspace, and a query that forgets to say which one is a failing build rather than a leak.

How it works

Reads and writes are scoped by company. A dedicated regression suite injects unscoped queries and asserts they are caught, so isolation is exercised on every commit rather than assumed.

Integrity enforced by the database

Duplicate invoices, duplicate carrier payments and replayed bulk operations are refused by constraints, not by whichever screen happened to check.

How it works

Unique indexes carry the rules the application also checks, so two requests arriving at the same moment cannot both win. Losing that race returns the same friendly refusal a single caller would have received.

Two-factor authentication

A password alone is not a session when an account has a second factor.

How it works

TOTP, compatible with standard authenticator apps, with single-use recovery codes stored hashed. The challenge is exchangeable only at the verification endpoint and is rejected everywhere else.

Session protection

One active session per account, and repeated failures stop being useful to an attacker.

How it works

Each token carries a session id, so signing in elsewhere ends the previous session. Failed attempts are counted and lock the account; authentication routes are rate limited more strictly than the rest of the API.

Password policy you control

The rules apply to every path that sets a password, including the first admin account.

How it works

Length and composition requirements are enforced server-side and configurable per workspace, with platform defaults for anyone who has not changed them.

Security audit trail

You can answer who signed in, from where, and what changed.

How it works

Sign-ins, failures, lockouts and settings changes are recorded as security events against the workspace, readable by an administrator.

Encrypted integration credentials

A third-party secret you store is never held in plaintext.

How it works

Credentials are encrypted before storage and every stored value carries the key version it was encrypted with, so keys can be rotated without losing what came before. No HTTP route returns a decrypted credential — a test enforces that.

Roles enforced on the server

What a person can reach does not depend on what their browser chose to render.

How it works

Admin, agent, sub-agent, billing, accounting and HR are checked on the route, not in the interface. Hiding a button is a courtesy; the refusal happens on the server.

Why this page is short.

Documentation, task guides and a public changelog belong here too. They are not written yet, so they are not listed yet — a link to an empty page is worse than no link. They will appear on this page when there is something behind them.

Ask us the hard question.

Start a 14-day trial and test the security model against your own workspace. No credit card required.