React to ticket changes

What you will build

Your app can react when a ticket is assigned or checked in. Eventlayer delivers the event; you choose what it does in your product.

Prerequisites

• A server endpoint that receives the raw request body.
• An endpoint signing secret and durable storage for incoming events.
• Dashboard access to configure the endpoint; API keys cannot manage webhooks.

1. Subscribe to the changes you need

Create an endpoint in the dashboard and select ticket.assigned and ticket.checked_in. Store its signing secret in your server environment. See endpoint configuration for the API equivalent.

2. Verify before processing

Inside your server's request handler, pass the unmodified body and request headers to the SDK. Signature verification throws if the request is invalid; reject that request instead of processing its payload.

import { verifyWebhook } from "eventlayer";

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

if (event.event_type === "ticket.checked_in") {
  // A typed ticket snapshot is available here.
  console.log(event.id, event.data.id, event.data.checked_in_at);
}

3. Persist, then acknowledge

Use a durable inbox or queue in your application. Enforce a unique constraint on event.id when recording incoming events, then acknowledge with a successful HTTP response. A repeated delivery should acknowledge the existing record. Process CRM, email or analytics updates from that durable work record. Those adapters and your persistence layer are application code you supply.

A replay creates a new delivery for the same event, so use event.id rather than only the delivery ID for this boundary. Keep failed processing jobs retryable within your inbox. Use a stable operation key or upsert when calling another provider so a worker retry can recover without repeating a completed side effect.

Test and recover

Return a failure if the event could not be durably recorded. Eventlayer can retry the delivery. Inspect attempt history and replay after resolving the problem. Test duplicate delivery, unavailable storage and a failing processing job before launch. Delivery order is not a substitute for reading the latest ticket state.

Next steps

Read Building webhook consumers that survive retries for the full consumer pattern, or the webhook reference for headers, verification and delivery operations.