Security
This page describes controls that exist in the product today, with links to the guides that explain each one. For where your data is processed and by whom, see Sub-processors.
Requests and access
- Signed requests. Every
/v1request carries a short-lived token signed with your API key's secret. The token lives at most 300 seconds, can be bound to one HTTP method and path, and the secret itself is never sent. Tokens in the query string are rejected because URLs end up in logs. See Authentication. - Account isolation. Each request resolves to one account from its API key, and data access is scoped to that account's ID. Accounts do not share signals, objects, events or answers.
- Console sign-in. Passwords are stored as bcrypt hashes and never in plain text. Two-factor authentication with an authenticator app is available, and its secret is stored encrypted. Signing in with Google or GitHub is optional.
- Rate limits. Requests are limited per account, and so is the number of inline (
wait) analyses running at once. See Errors and retries.
Secrets
- API key secrets are encrypted at rest with AES-256-GCM under a versioned master key. The server needs the secret to verify a signature, so it cannot store only a hash. Master keys can be rotated without invalidating keys, and you can rotate an individual key's secret at any time. See API keys.
- Webhooks are signed. Each delivery carries an HMAC-SHA256 signature over the timestamp and raw body, which your endpoint should verify. See Webhooks.
Message content
What reaches an analysis provider. For each analysis, SigWise sends the provider the object's ID and type, its recent events (type, name, content, metadata and time), a rolling summary of older events, and the definitions of the signals being scored. It does not send your API keys, your account email, your billing data or any other object's events. Which provider analyses an account is described in Sub-processors.
What is stored. Events are kept according to the retention policy you choose: forever, for a number of days, or only until an analysis has read them. Inline checks with wait set to true can be configured so content is never written. Answers are kept whichever policy you choose, so reads, rules and webhooks keep working. See Data retention.
What is not logged. The API handlers and the analysis engine do not write message content to application logs.
Deletion
One call deletes everything stored about an object: its events, answers, summary, queued analysis, rule history and webhook deliveries. Billing records keep the object ID they were charged for, as financial records. See Data retention.
By default, delivered webhook records are removed after 30 days, sent email records after 90 days and rule firing records after 90 days. The billing ledger is never pruned.
Transport
The hosted API and console are served over HTTPS.
Scope
This page describes product controls. It is not a certification report.