Building webhook consumers that survive retries

Pass the unmodified request body and headers to the SDK’s verification helper. Use the endpoint signing secret, which is separate from your API key. Verification throws for an invalid request; reject it before recording or acting on the payload.

import { verifyWebhook } from "eventlayer";

const event = await verifyWebhook({
  body: await request.text(),
  headers: request.headers,
  secret: process.env.EVENTLAYER_WEBHOOK_SECRET!,
});

// Record event.id and its payload in your durable inbox.
// Acknowledge only after that write succeeds.

Return a successful response after validating and durably queueing the event. Keep email, CRM updates, analytics, and other expensive work out of the request path so a slow dependency does not turn into a failed webhook attempt.

Eventlayer uses an at-least-once delivery model, so the same event may arrive more than once. Enforce a unique constraint on event.id in your consumer’s inbox. A replay creates a new delivery for the same event, so deduplicating only a delivery ID leaves a replay able to repeat the side effect.

A duplicate request can acknowledge the existing inbox record. Retry failed processing from that record separately. For work sent to another provider, use a stable operation key or an upsert where supported: an inbox alone cannot make a remote side effect and your database one transaction.

Do not treat arrival order as resource state. Fetch the current Eventlayer resource when correctness depends on the latest value, or make the update in your own system depend on a known business state. An old ticket snapshot arriving later should not undo a more recent cancellation or check-in.

Use attempt history to inspect the destination, response status, duration, and bounded error details. After your endpoint recovers, replay the delivery from Eventlayer instead of writing a one-off data repair or rebuilding a delivery scheduler.