Skip to main content
A webhook sends a POST request to your URL each time a chosen event happens in your organization: a customer writes in, a ticket is created or closed, an agent changes its status. Use webhooks to mirror tickets into your CRM, alert your team, or relay the AI agent’s replies to a channel you run. Manage webhooks in Settings > Webhooks, or with the API below. Every request goes to https://back.leap.onclarity.com with Authorization: Bearer $CLARITY_API_KEY (see Authentication).
These webhooks cover chat, email, and ticket events. For a summary of each finished voice call, use the Voice API’s call-ended webhook.

Set up a webhook

1

Find the event ids

GET /api/webhooks/events/list returns the events your organization can subscribe to. Each has a numeric id, a key (for example message), and a display_name.
specs is free-form information about the event, such as a description. Pass specs=false to get specs as null.The ids differ between environments, so look them up rather than hard-coding them. The list pages with limit (default 20) and offset.
2

Create the webhook

string
required
The http or https URL Clarity posts to.
integer[]
default:"[]"
The events to send. An unknown id answers 404 webhook_event_not_found.
string
default:"active"
active or disabled. Only active webhooks receive events.
The response is the webhook:
3

Handle the requests

Answer each request with a 2xx status within 30 seconds. See Delivery.

Manage webhooks

Delivery

Each event is sent to every active webhook subscribed to it.
Requests are not signed and carry no secret or authentication header. Treat the payload as a notification: use a URL that is hard to guess, accept only POST, and when an action matters, read the current state back from the API (for example the ticket details) instead of trusting the body alone.
Design your handler to tolerate duplicates. A request that timed out on your side may still be retried, so the same event can arrive more than once. The payload carries no event id; deduplicate on the fields that identify the change, such as ticket_id with type.

Event catalog

The catalog can also list voice_call_ended and voice_call_warning. They trigger workflows and are not delivered to webhook URLs. Use the Voice API’s call-ended webhook for calls.

Payloads

Ids in payloads are the same ids the API uses: ticket_id works with the ticket endpoints, agent_id with GET /api/agent/list, status, priority, and category ids with their lookup endpoints.

Messages

agent_id is null when the customer wrote the message. For a reply it is the id of the agent who sent it; check kind in GET /api/agent/list to tell the AI agent (ai) from a human (human). files holds attachment ids.
This payload has no ticket_id.
template_id is currently always an empty string.
trigger_internal_id is the internal_id of the prompt being answered.

Ticket lifecycle

customer has the shape of the customer object. channel is web, android_sdk, ios_sdk, whatsapp, email, voice, x, instagram, linkedin, or social.
transcript holds the ticket’s messages and private notes, oldest first; status and assignment events are left out. sender_type is customer, human, or ai. ticket.custom_attributes includes every attribute the ticket holds. thread_root_id is the first ticket of the chat when this ticket continues an earlier one.If the ticket could no longer be read when the event was sent, the payload carries only type and ticket_id.

Customer feedback and forms

Knowledge base and incidents

Sent for articles created in Clarity, through the API, and from uploads (an upload sends it when the article is created, while its status is still processing).
action says what happened: detected for incident_detected; resolved or auto_resolved for incident_resolved; and for incident_updated one of created, confirmed, dismissed, edited, monitoring, reactivated, reopened, banner, guidance, voice_notice, or deleted. status is suspected, active, monitoring, resolved, or dismissed; origin is manual or detected.