Webhooks. Real-time events, delivered reliably.

Read the raw request body as bytes (before any JSON parsing), compute HMAC-SHA256 over the raw bytes using your endpoint's shared secret, base16-encode (hex) the result, and compare it to the value in the X-Elido-Signature header after stripping the 'sha256=' prefix. Use a constant-time comparison function (e.g., hmac.compare_digest in Python, crypto.timingSafeEqual in Node.js) to prevent timing attacks. Never compare the signature with a standard string equality operator. Code examples for Node.js, Python, and Go are at /docs/guides/webhooks#verification.

Return HTTP 200 (or any 2xx status code) within 30 seconds. The response body is ignored — you can return an empty body or { ok: true }. If your processing takes longer than 30 seconds, return 200 immediately and process the event asynchronously (enqueue to an internal queue, return 200, process off the request path). Returning 4xx is treated the same as 5xx for retry purposes — both trigger a retry. Return 200 even if the event is not relevant to your integration (e.g., a link.created event you don't need) to avoid spurious retries.

Every webhook payload includes an event_id field (UUID). Use this as the idempotency key on your receiver: if you receive the same event_id twice (due to a retry after a partial failure), process it only once. Store received event IDs in a deduplication table with a TTL of at least 72 hours (the retry window). The retry payload is identical to the original — same event_id, same body — so a simple 'have I seen this event_id?' check is sufficient.

Endpoints are auto-paused after 30 consecutive delivery failures (non-2xx or timeout). This prevents Elido from hammering a broken endpoint indefinitely. Fix the underlying issue (usually: the endpoint URL changed, the server is down, or the 30-second timeout is being exceeded due to slow processing), then resume the endpoint in the dashboard. Once resumed, Elido does not automatically replay events that were skipped during the pause — replay them manually from the delivery log if you need to recover those events.

Yes — enable raw-click mode on the endpoint. In raw-click mode, Elido delivers click.created events individually with no batching window, within 2 seconds of the click. Be aware that a busy workspace can produce thousands of events per minute in raw-click mode; ensure your receiver can handle the throughput. For most analytics use cases, the default 5-second batched aggregation (up to 100 clicks per payload) is sufficient and produces far fewer HTTP requests.

Individual event payloads are under 10KB. Batched click payloads (default mode) can be up to 100 events per batch, with a total payload size cap of 100KB. If a batch would exceed 100KB, it's split into multiple deliveries automatically. Large metadata fields on clicks (e.g., long referer URLs) are truncated at 2KB per field. If your receiver enforces a strict payload size limit, configure raw-click mode (one event per delivery) instead of batched mode.

Use a tool like ngrok, Cloudflare Tunnel, or localtunnel to expose your local server with a public HTTPS URL, then register that URL as a webhook endpoint in your test workspace. Alternatively, use the webhook test-fire button in the dashboard to send a sample payload for any event type to a registered endpoint without triggering a real event. The Elido CLI (elido webhook test --event click.created --endpoint https://...) also works for scripted local testing.

Events generated during a maintenance window are queued in Redpanda and delivered after the maintenance window ends. The Elido status page (status.elido.app) announces planned maintenance windows in advance. Webhook delivery SLA excludes announced maintenance windows. For the typical 30–60 minute maintenance window, the 72-hour retry window means no events are permanently lost — they're delivered in the order they were generated once the endpoint is reachable again.