Skip to main content
Precipiq is built around the principle that you should be able to verify what happened to your data without taking our word for it. Every decision record is hash-linked so tampering is detectable, forensic exports carry a cryptographic signature you can verify offline, and your API keys are stored only as hashes — we can’t recover them if you lose them.

Authentication

Precipiq uses API keys to authenticate all requests.
  • Keys are 32-byte secrets prefixed with pq_live_ for production or pq_test_ for sandbox environments.
  • Keys are stored by their SHA-256 hash only. The raw key is shown exactly once — at generation — and is never logged.
  • WebSocket connections authenticate via an api_key query parameter. Browsers cannot set custom headers on the WebSocket handshake, so the query parameter is the required mechanism. Precipiq scrubs this parameter from access logs automatically so your key does not appear in log output.
Use pq_test_ keys during development and integration testing. They are isolated from your production ledger and carry their own rate limits.

Hash chain tamper detection

The ledger is append-only and hash-linked. Every decision record stores the SHA-256 of its predecessor in prev_hash, and its own hash is computed over a canonical JSON serialisation that includes prev_hash. Altering any single record corrupts the chain at every subsequent record — detectable in a single verify_chain sweep. See Hash Chain for a detailed explanation of how the chain is constructed and how to run verification yourself.

Encryption

In transit

All traffic between your application and the Precipiq API travels over TLS 1.2 or higher. The dashboard enforces HSTS with a two-year preload window, preventing protocol downgrade attacks.

At rest

WhatHow
Ledger dataAES-256 disk encryption at the storage layer.
Forensic export signing keysPer-org RSA-2048 private keys, encrypted at rest with a master secret held in a key management service. The private key never exists in plaintext outside the signing process.

Threat model

ThreatMitigation
API key leaked in client codeSandbox keys (pq_test_*) for development; per-org rate limits; key rotation endpoint.
Replayed Stripe webhookstripe-signature header verified; external_id idempotency prevents double-processing.
Mass reconnect from a shared IPPer-IP WebSocket connection rate limit (30 per minute per IP).
Slow-consumer denial of serviceBounded per-connection queue; connections evicted on overflow.
Attacker with database write access alters historyHash chain detects the alteration on the next verify_chain sweep.
Forensic bundle altered after exportRSA-2048 signature on manifest.json; recipient verifies with openssl dgst -verify without contacting Precipiq.
Cross-org data leakageEvery query is scoped to your organisation; strict data isolation is enforced at the database layer.

Dependency hygiene

All Python and Node dependencies are version-pinned and audited for known vulnerabilities on every release. No runtime dependency on unmaintained packages.

Compliance roadmap

These are planning targets, not commitments. Contact sales for the current status of any specific attestation.
  • SOC 2 Type II — planned; target window Q3 2026 subject to audit scheduling.
  • ISO 27001 — being scoped for 2027.
  • HIPAA BAA — available on the Business plan and above. Contact sales for the signed BAA template.

Responsible disclosure

If you discover a security issue, email security@precipiq.dev with a proof of concept. We aim to acknowledge within two business days and will coordinate disclosure timing with you before any public write-up.
Precipiq does not run a public bug bounty program. Individual bounty arrangements are possible by prior agreement.