Tokens never stored in plaintext
Source ingest tokens are stored as SHA-256 hashes. Validation is constant-time. Tokens are never written to logs or audit trails — only their hash prefix.
SHA-256Security
Built so the on-call engineer sleeps through the night.
Webhook traffic carries some of the most sensitive data in your stack — payment events, identity changes, access grants. Axel is engineered like the systems your security team is already comfortable with.
Implemented controls
Security controls in the product today.
The controls below are implemented in the current product. Planned certifications and additional controls are listed separately on the roadmap.
Payloads encrypted in transit & at rest
TLS 1.2+ on the edge. Cloudflare R2 encrypts every object at rest. ClickHouse logs are stored in customer-managed encryption keys when self-hosted.
TLS 1.2+Declarative route rules, not customer code
Route filters and transforms use an eval-free declarative language. The router does not execute customer JavaScript or expose network, filesystem, or process primitives to route configuration.
no evalTenant isolation by workspace_id
Postgres rows, ClickHouse records, object keys, and queue messages carry workspace scope. Dashboard and service queries require the active workspace identifier.
workspace scopedBounded payload retention
Defaults are 30 days for raw payloads and event traces, 90 days for dead letters, 30 days for replay-request records, and 365 days for audit logs. Configurable ranges are documented below and enforced by scheduled drains.
30 daysAudit log on every privileged action
Workspace creation, member invites, role changes, source mutations and destination writes are all recorded with actor + timestamp in an append-only audit log.
append-onlyRoadmap
The compliance work, sequenced honestly.
We'd rather you see the plan than a logo soup. Here's where the security work sits today, and where it's going next.
- ShippedTLS edge, hashed tokens, declarative transforms, audit log
- ShippedPer-source rate limits, body & depth caps, stable delivery IDs
- ShippedEgress guards on every destination connector — private-network and SSRF targets rejected, including connection tests
- ShippedVersioned signing secrets bound to their source, constant-time sign-in, fail-closed ingest
- ShippedRelease gate: every version passes a deterministic check suite plus an adversarial audit before deploy
- In flightSelf-serve GDPR erasure for data-subject requests
- Q3 2026SOC 2 Type I report (in observation now)
- Q4 2026BYO-cloud option for regulated workloads
- 2027SOC 2 Type II + ISO 27001
FAQ
Is Axel secure, and how is my data handled?
Is Axel secure?
Axel encrypts payloads in transit (TLS 1.2+) and at rest, stores ingest tokens as SHA-256 hashes, scopes data access by workspace_id, evaluates only declarative route rules, and records privileged actions in an append-only audit log.
Is Axel SOC 2 compliant?
Axel is in a SOC 2 Type I observation period, with the Type I report planned for Q3 2026 and SOC 2 Type II plus ISO 27001 targeted for 2027. The underlying controls — encryption, tenant isolation, audit logging, and egress guards — are already in place.
How does Axel handle and store my data?
By default, raw webhook payloads and event traces are retained for 30 days, dead letters for 90 days, replay-request records for 30 days, and audit logs for 365 days. Configurable ranges are 0–30 days for raw payloads, 1–365 for dead letters, 1–90 for replay requests, and 30–3,650 for audit logs.
How is one customer's data isolated from another's?
Postgres rows, object-storage keys, queue messages, and analytics records carry a workspace identifier. Dashboard and service queries require workspace scope, and authorization checks bind requests to the active workspace.
What should my sender do if Axel is unavailable?
Treat a missing 202 response as an unaccepted event and retry according to the sender's webhook policy. Axel only returns 202 after it has accepted and stored the original payload.
Have a security question?
We respond to security@axelapp.ai within one business day. Vulnerability reports get a same-day acknowledgement and a fix or mitigation timeline within 72 hours.