Everything you need to run webhooks in production.

curl -X POST https://app.axelapp.ai/api/v1/sources \
  -H "Authorization: Bearer $AXEL_API_KEY" \
  -d '{ "name": "my-webhook" }'

POST https://ingest.axelapp.ai/in/{source_id}
  x-axel-token: <token>
  content-type: application/json

  { "type": "order.created", "id": "ord_123", ... }

Prefer the CLI? Create a source in the dashboard, then axel auth login and axel listen --source <source_id> --forward-to <url>, or point your webhook producer at the ingest URL shown in the dashboard.

• Per-source rate limits (events/min, operator-configured) protect downstream systems.
• Body cap (1 MB default) and depth cap (100 levels) reject pathological payloads early.
• An accepted event is written to R2 before the 202 response is sent.
• Token values are stored only as SHA-256 hashes; never in logs.

{
  "event_id": "evt_01HZQ8R7XK",
  "source": "stripe.webhooks",
  "event": "invoice.paid",
  "customer": "cus_PqJ8XKr",
  "amount": 14250,
  "currency": "usd",
  "routes": ["payments.live"]
}

Routes: declarative filters & transforms

Routes decide where events go and what they look like. Rules are data, not code.

• Filter by event type (e.g. payments.live matches invoice.paid etc.).
• Declarative transforms: select/rename fields by JSON path, drop fields, pass the whole payload through, or wrap it as a JSONB column.
• The route engine is eval-free and does not execute customer JavaScript.
• Fan-out to many destinations from one source with per-(route, destination) idempotency keys.

Destinations

Deliver with retries to the systems you already run.

• Signed webhook: POST with HMAC + deterministic idempotency header so receivers can dedupe safely.
• Postgres: insert into a JSONB column or auto-flattened columns (column projection). MongoDB: insert into native collections.
• S3: write JSON objects with templated keys ({date}, {event_id}). Cloudflare R2: write JSON objects under a configurable key prefix.
• Databricks: drop JSON files into Unity Catalog volumes for Auto Loader ingest into Delta.
• BigQuery: stream each event into a table via insertAll. New routes recursively map JSON objects to nested RECORD fields, normalize scalar leaves to STRING for schema-drift tolerance, and map compatible object arrays to REPEATED RECORD fields. Axel creates the table when needed and additively evolves nested schemas; legacy flat-column and single-STRING-column modes remain available.

Delivery guarantees & idempotency

Axel provides at-least-once delivery to external destinations. Delivery attempts use a stable key of the form workspace:event:route:destination, and retries reuse that key. A signed HTTP receiver should deduplicate on X-Axel-Event-Id because a process can fail after the destination accepts a request but before Axel records the acknowledgement. Replays use a new event ID and are intentionally delivered again.

From the dashboard or CLI:

# Dashboard: click any event → Replay
# CLI (exact bytes to your laptop)
axel replay evt_01HZQ8R7XK --forward-to http://localhost:3000/webhook

• Replays pull the original payload + headers from R2 (up to 30-day retention).
• Provider signature headers (Stripe, GitHub, Shopify, Axel) are stripped by default since their signed timestamp is stale; pass --keep-signature to forward them anyway.
• Each replay gets a distinct, replay-tagged event id so the re-delivery is recorded separately from the original.

Failed deliveries & the Inbox

Every delivery attempt is recorded. Permanent failures (after all retries) land in the Inbox with one-click Retry and Mute. No SQL, no digging through DLQ tables.

The event detail page shows the receipt, the stored payload, and a delivery history of every HTTP attempt with its status, latency, and the failure reason (TLS error, 503, timeout, etc.).

Transform & route errors

If a declarative filter excludes an event it is dropped; if a transform or filter errors at runtime the event is dead-lettered and shows up in the Inbox. Oversized or too-deep payloads are rejected at ingest with a 413 before they are ever stored or routed.

Scaling knobs

• Per-source rate limits + body/depth caps are your first line of defense.
• Router and delivery workers use bounded concurrency and sharded queues (Cloudflare Queues + internal).
• Raw payloads: 30 days by default (0–30 configurable). ClickHouse traces: 30-day TTL.
• Dead letters: 90 days by default (1–365 configurable). Replay requests: 30 days by default (1–90 configurable).
• Audit logs: 365 days by default (30–3,650 configurable).
• Dashboard and API give you per-route and per-destination delivery metrics, including p95 delivery latency.

Every stored event carries Axel metadata and a pointer to the raw body in R2 (the body is referenced by r2_key rather than inlined). Example shape:

{
  "event_id": "evt_01HZQ8R7XK",
  "workspace_id": "ws_...",
  "source_id": "src_...",
  "received_at": "2026-06-16T14:22:09.123Z",
  "r2_key": "...",
  "size_bytes": 1024,
  "headers": { "x-my-signature": "..." },
  "query": {}
}

Retry policy (defaults)

Up to 12 delivery attempts with exponential backoff. Retries are included in the inbound event price. The retry policy is fixed and not per-source configurable.

ClickHouse observability

All receipt, routing, and delivery rows are queryable in ClickHouse for 30 days (headers, query params, and failure reasons; raw payloads live in R2). The dashboard search and the axel CLI use these tables. Export or run your own queries from the usage / deliveries views.

Important status & error reasons

• 202: accepted (written to R2, queued for routing)
• 429: rate limited at source
• 413 / depth errors: body or nesting exceeded caps
• Signature / auth failures: rejected before durable store
• Destination 5xx, timeouts, and connection errors: retried per policy, then DLQ
• Permanent 4xx (e.g. 400/401/403/404/410): dead-lettered immediately