Security & privacy
Webhook payloads contain real data — customer records, order details, account changes. If you run catchbin as a production parallel receiver, you are sending that data to catchbin, so this page states plainly what happens to it.
Encryption at rest
Section titled “Encryption at rest”Every stored payload is encrypted at the application layer with a key scoped to your workspace (AES-256). catchbin uses envelope encryption: a key-encryption key held in the platform’s secret store wraps a per-workspace data-encryption key. Captured request headers are encrypted under the same envelope as the body.
The practical consequence: a leak of the database’s own credentials does not yield readable payloads, because the data is encrypted with keys the database does not hold. Row-level security enforces the workspace boundary as a second wall, and all connections use TLS 1.2 or higher.
What catchbin never logs
Section titled “What catchbin never logs”Structured logging is a hard rule in catchbin. A payload — raw or decrypted — a webhook secret, a full header, or any key material never appears in a log line at any level. Denylisted token names (Authorization, X-API-Key, webhook_secret, Cookie, and others) are scrubbed before anything is written. Signature diagnostics show only the body byte count and a safely-truncated header fragment — never the secret or the body.
Signing secrets are write-only
Section titled “Signing secrets are write-only”You enter a signing secret once. It is stored encrypted and is never returned through the API or shown in the dashboard again. Changing a signing secret is a step-up-authenticated action — it requires a fresh re-authentication even within a logged-in session.
Masking and metadata-only
Section titled “Masking and metadata-only”Two controls let you reduce what is stored:
- Credential-header masking. Values of credential headers (
Authorization,Cookie, …) are masked in the dashboard by default, with an explicit reveal.curlexport keeps them masked unless you ask for the unmasked form. - metadata-only mode. An endpoint set to
metadata_onlyreads the body into memory to verify the signature and extract the event type, then discards it — the body is never written to disk, database, or logs. See Operating modes.
Retention and deletion
Section titled “Retention and deletion”Captured events are retained for the length of your plan’s retention window and then purged. Events above your plan’s storage limit are removed oldest-first by an hourly cleanup. You can set a shorter retention window than your plan’s maximum, and you can delete individual events or request erasure of all your data.
Replaying production data
Section titled “Replaying production data”Replaying a production event to a staging or local target moves real customer data into that environment. catchbin surfaces a warning on production-to-non-production replay, but the decision — and the data-handling obligation — is yours.
Hosting and sub-processors
Section titled “Hosting and sub-processors”catchbin runs on:
- Supabase — Postgres, authentication, and object storage.
- Fly.io — application compute.
- Cloudflare — the marketing site and dashboard delivery, and DNS.
- Stripe — billing (when paid plans are live).
Your responsibilities
Section titled “Your responsibilities”Webhook payloads contain PII by nature. Under data-protection law, catchbin is a data processor and you are the data controller. A GDPR data-processing agreement is available for EU customers. catchbin does not currently hold a SOC 2 report; that is on the roadmap if enterprise demand warrants it.