Webhooks. Realtime events, betrouwbaar afgeleverd.

Lees de ruwe requestbody als bytes (vóór enige JSON-parsing), bereken HMAC-SHA256 over de ruwe bytes met het gedeelde secret van je endpoint, base16-encodeer (hex) het resultaat en vergelijk het met de waarde in de X-Elido-Signature-header na het strippen van het 'sha256='-prefix. Gebruik een constant-time vergelijkingsfunctie (bijvoorbeeld hmac.compare_digest in Python, crypto.timingSafeEqual in Node.js) om timing-attacks te voorkomen. Vergelijk de signature nooit met een standaard string-gelijkheidsoperator. Codevoorbeelden voor Node.js, Python en Go staan op /docs/guides/webhooks#verification.

Geef HTTP 200 terug (of elke 2xx-statuscode) binnen 30 seconden. De responsbody wordt genegeerd - je kunt een lege body of { ok: true } teruggeven. Duurt je verwerking langer dan 30 seconden, geef dan direct 200 terug en verwerk het event asynchroon (zet het in een interne queue, geef 200 terug, verwerk buiten het requestpad). Het teruggeven van 4xx wordt voor retrydoeleinden hetzelfde behandeld als 5xx - beide triggeren een retry. Geef 200 terug, ook als het event niet relevant is voor jouw integratie (bijvoorbeeld een link.created-event dat je niet nodig hebt), om overbodige retries te voorkomen.

Elke webhookpayload bevat een event_id-veld (UUID). Gebruik dit als idempotency-key op je ontvanger: krijg je hetzelfde event_id twee keer (door een retry na een gedeeltelijke mislukking), verwerk het dan slechts één keer. Sla ontvangen event-ID's op in een deduplicatietabel met een TTL van minstens 72 uur (het retryvenster). De retry-payload is identiek aan de originele - hetzelfde event_id, dezelfde body - dus een eenvoudige controle van 'heb ik dit event_id al gezien?' is voldoende.

Endpoints worden automatisch gepauzeerd na 30 opeenvolgende afleverfouten (non-2xx of timeout). Dit voorkomt dat Elido een kapot endpoint eindeloos blijft bestoken. Los het onderliggende probleem op (meestal: de endpoint-URL is gewijzigd, de server is offline, of de time-out van 30 seconden wordt overschreden door trage verwerking), en hervat het endpoint dan in het dashboard. Eenmaal hervat, speelt Elido events die tijdens de pauze zijn overgeslagen niet automatisch opnieuw af - speel ze handmatig opnieuw af vanuit het afleverlog als je die events wilt herstellen.

Ja - schakel raw-click-modus in op het endpoint. In raw-click-modus levert Elido click.created-events individueel af, zonder batchvenster, binnen 2 seconden na de click. Houd er rekening mee dat een drukke workspace duizenden events per minuut kan produceren in raw-click-modus; zorg dat je ontvanger de doorvoer kan verwerken. Voor de meeste analyticsusecases is de standaard gebatchte aggregatie van 5 seconden (tot 100 clicks per payload) voldoende en levert veel minder HTTP-verzoeken op.

Individuele eventpayloads zijn kleiner dan 10KB. Gebatchte click-payloads (standaardmodus) kunnen tot 100 events per batch bevatten, met een totale payloadgrootte van maximaal 100KB. Zou een batch de 100KB overschrijden, dan wordt deze automatisch opgesplitst in meerdere afleveringen. Grote metadatavelden op clicks (bijvoorbeeld lange referer-URL's) worden afgekapt op 2KB per veld. Legt jouw ontvanger een strikte limiet op payloadgrootte op, configureer dan raw-click-modus (één event per aflevering) in plaats van gebatchte modus.

Gebruik een tool als ngrok, Cloudflare Tunnel of localtunnel om je lokale server met een publieke HTTPS-URL bloot te stellen, en registreer die URL vervolgens als webhookendpoint in je testworkspace. Je kunt ook de webhook test-fire-knop in het dashboard gebruiken om een voorbeeldpayload voor elk eventtype naar een geregistreerd endpoint te sturen zonder een echt event te triggeren. De Elido CLI (elido webhook test --event click.created --endpoint https://...) werkt ook voor scripted lokaal testen.

Events die tijdens een onderhoudsvenster worden gegenereerd, worden in onze event-stream gequeued en afgeleverd zodra het onderhoudsvenster is afgelopen. De Elido-statuspagina (status.elido.app) kondigt geplande onderhoudsvensters vooraf aan. De webhook-afleverSLA sluit aangekondigde onderhoudsvensters uit. Bij het typische onderhoudsvenster van 30–60 minuten betekent het retryvenster van 72 uur dat er nooit events permanent verloren gaan - ze worden afgeleverd in de volgorde waarin ze zijn gegenereerd, zodra het endpoint weer bereikbaar is.