Security

Webhooks carry your customers’ data and your credentials. This is what we do about it, and what we do not claim.

Accounts and access

Passwords are hashed with argon2id. Sign-in is rate limited and accounts lock after repeated failures; responses never reveal whether an email is registered.
Optional two-factor authentication (TOTP) with single-use recovery codes. Two-factor is mandatory for platform administrators.
Sessions use HttpOnly, Secure, SameSite cookies, can be listed and revoked, and every state-changing browser request is protected against CSRF.
Roles (Owner, Admin, Developer, Viewer, Billing Manager) are enforced on the server for every request. API keys are shown once, stored only as hashes, scoped, rotatable and revocable.

Tenant isolation

Every customer-data query goes through an organization-scoped data layer; cross-organization requests answer “not found”. Isolation is covered by automated tests for every resource type, at the data layer and through the API and browser.

Protecting what you send us

Provider signatures (Stripe, GitHub, Shopify, generic HMAC) are verified against the raw request body with constant-time comparison, with timestamp tolerance against replays.
Destination signing secrets, source verification secrets and two-factor secrets are encrypted at rest with AES-256-GCM using versioned keys that support rotation.
Secrets are never logged and never returned after creation; custom header values are hidden in the UI and redacted in stored attempt records.

Protecting your servers and ours

Outbound requests are signed (timestamped HMAC-SHA256) so you can verify they came from Retryx; signing-secret rotation has an overlap window so you can switch without downtime.
Server-side request forgery protection: destinations must be HTTPS and cannot target private, loopback, link-local, carrier-grade NAT, multicast or cloud-metadata addresses (IPv4 and IPv6, including mapped and encoded forms). URLs are validated when saved and again before every delivery; DNS is resolved once and the connection is pinned to the validated address to defeat DNS rebinding; redirects are off by default and re-validated per hop.
Request and response sizes are bounded, timeouts are enforced, and payload transformations are declarative (no customer code runs on our infrastructure).

Operations and accountability

Administrative actions require typed confirmation and a written reason, and are recorded in an append-only audit log that the database itself refuses to modify or delete.
Rate limits and abuse controls apply to ingestion and the API; traffic anomalies are surfaced to operators.
Payload retention is limited by plan; event metadata and usage records are kept for billing and audit.
The service runs on managed PostgreSQL and Key Value infrastructure over private networking with TLS. Database state is the source of truth; queues can be rebuilt from it.

What we do not claim

Retryx has not completed a SOC 2 or ISO 27001 audit and does not currently offer a contractual SLA or data-processing addendum as a standard product. If you need those, tell us and we will be straightforward about where we stand.

Delivery is at-least-once, not exactly-once: your handler should de-duplicate on the Idempotency-Key header. Ordering is not guaranteed.

Found a vulnerability? Please report it privately through the contact form (mention “security”) and give us a chance to fix it before disclosing publicly.