Trust & Security

Rate-limited by design

Signup and per-key request rates are capped server-side (5/hour on signup, per-key limits on assessment calls). This isn't a gateway bolted on after the fact — it's in the request path itself.

Every action is audited, and the log checks itself

Key creation, revocation, team changes, sign-ins, and account deletion write to a hash-chained audit log per tenant — each entry seals in the one before it, so editing or deleting a past entry breaks every hash after it. That's re-verified, not just displayed, every time you open Activity. This makes tampering detectable, not impossible: it's tamper-evident, and we say so rather than overclaiming tamper-proof.

API versioning that won't break you

Every endpoint is reachable both unversioned and under /v1/ — pick either today, both keep working. Nothing gets deprecated out from under an existing integration without real notice first.

Real read-only access

A workspace's Viewer role isn't a hidden button in the dashboard — the server itself rejects a Viewer's key-creation or webhook-change request with a 403, even called directly against the API with no UI involved at all.

Evidence is tamper-evident

The evidence behind a recorded decision is sealed with a SHA-256 hash at the moment it's written. Re-opening that decision later re-verifies the hash — if the stored evidence had been altered, the page would say so, not silently show it.

Payment webhooks are verified

Billing events from Paddle are checked against an HMAC-SHA256 signature with a timestamp tolerance window, compared using a constant-time comparison — the standard defence against both forged events and timing attacks on the check itself.

Your alert webhooks are resilient, not just fired once

A drift alert to your own webhook retries up to 3 times over a few seconds if your endpoint is briefly unreachable — a one-second network blip no longer means a silently dropped notification. A deliberate rejection from your endpoint (4xx) is not retried; that would not help.

Every response carries a correlation id

An X-Request-Id header on every response, generated per request if none was already set upstream — or echoed back unchanged if your own gateway already assigned one. When something needs debugging, this is the one value that ties a customer's report to the exact request in the logs.

Repeat a call safely with Idempotency-Key

Session-authenticated actions are rate-limited too

A compromised session can't be used to mint API keys, spam invitations, reconfigure your webhook, hammer the billing API, or flood decision transitions unbounded — each of these has its own independent hourly cap, separate from your plan's own quotas, which exist for a different reason and shouldn't be the only backstop.

What we keep for Rebuild — stated plainly, by plan

If you build a baseline by uploading a CSV, we keep a bounded number of your most recent uploads per model — not just the latest, so a recent-but-not-current baseline can still be rebuilt — and prune anything older automatically: Free keeps 1, Pro keeps 5, Business keeps 20, Enterprise keeps 50. We do not retain data sent to the plain /fit API — that can come from any pipeline of any size, and remembering everything ever sent there is a materially bigger retention footprint we haven't taken on.

Sessions can be revoked

Changing your password or using "sign out everywhere" invalidates every existing session token immediately, not just the one in front of you — enforced server-side via a version counter on the account, not a client-side flag.

Deletion is actually complete

Account deletion removes the account, its models, its keys, and its decision history — verified by an automated test that checks every table, not just the obvious ones, after every deletion.