Set up Axel. Send your first webhook.

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

curl -X POST "$AXEL_INGEST_URL" \
  -H "x-axel-token: $AXEL_SOURCE_TOKEN" \
  -H "content-type: application/json" \
  -d '{ "type": "order.created", "id": "ord_123" }' 

Create a source in the dashboard, then point your webhook producer at the ingest URL it shows. With the Axel CLI, run axel auth login and axel listen --source <source_id> --forward-to <url> to forward new events to a local handler.

• Per-source rate limits (events/min, operator-configured) protect downstream systems.
• The default limits reject bodies over 1 MB and nesting deeper than 100 levels.
• An accepted event is written to R2 before the 202 response is sent.
• Axel stores source tokens as SHA-256 hashes. Use headers when your sender supports them; authenticated URLs can appear in sender or proxy 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 choose destinations and define which fields each destination receives.

• Filter by event type or payload fields, then preview which events match.
• 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.
• Send one source to multiple destinations. Each route and destination pair has its own delivery idempotency key.

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. Enable Allow new fields on the route binding to add fields to an existing table automatically. Otherwise, update the schema yourself. Axel does not widen existing column types. 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.

Use the dashboard to replay through your routes. Use the CLI to send stored bytes directly to a local handler:

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

• Replay requires the original payload to remain in storage. Retained metadata excludes authentication and other sensitive headers.
• The CLI strips supported provider signature headers by default. --keep-signature preserves only headers still present in the retrieved metadata; it cannot restore headers removed at ingestion or make an expired signature valid.
• Dashboard replays create a new event ID. CLI forwarding goes directly to your handler and does not create an Axel delivery record.

Failed deliveries & the Inbox

Terminal failures appear in the Inbox after retries are exhausted or the destination returns a non-retryable error. Open the failure to inspect its history, retry after a fix, or mute it.

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.

Capacity and retention

• Set per-source rate limits and payload limits to control incoming traffic.
• Router and delivery workers use bounded concurrency and sharded queues (Cloudflare Queues + internal).
• Axel Cloud raw payloads: 30 days by default, configurable from 0 to 30. ClickHouse traces expire after 30 days.
• 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": {}
}

Default retry policy

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.

Event storage and search

ClickHouse stores receipt, routing, and delivery metadata for 30 days. The dashboard and CLI use it for event search and delivery history. Raw payloads stay in R2.

Response codes and failure 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