How do I send Kickcall events to my systems with webhooks?

Create HTTPS webhook destinations in Kickcall, select events, review delivery logs, and check whether event data reaches your CRM or internal system.

Written By Maruf Ansari

Last updated 9 days ago

Webhooks push events from Kickcall to your own systems the moment they happen — no polling needed. You find them under Configuration → Agency Only → Webhooks.

Webhooks Overview

Webhooks allows developers and technical Agency team members to automatically send Kickcall event data to external systems through configured HTTPS destinations. You can use webhooks to sync call outcomes with a CRM, update dashboards when appointments are booked, or trigger internal workflows when calls are missed. The page includes two tabs: Webhooks for creating, editing, and deleting destinations, and Logs for reviewing delivery attempts and their results. This helps Agencies automate processes and monitor event delivery to connected systems.

Important notes

Endpoints must use HTTPS so data is encrypted in transit.
Subscribe only to events you process. Fewer events means less noise in Logs.
Edits to a webhook apply to future deliveries only.

Before you start

A publicly reachable HTTPS endpoint to receive event data.
A list of the events your integration actually processes.

Create a webhook

Go to Configuration → Webhooks and click Create Webhook.

Enter the Endpoint URL — the HTTPS URL on your side that will receive the event payloads.

Enter a Destination Name — a friendly label, so you can recognise it in the list and in logs.

Add a Description explaining what this webhook is for.

Tick the Events you want delivered. Events are grouped by category (Call, Contact, Appointment, and more), and you can select an entire category with its group checkbox. The counter at the top right shows how many of the available events you have selected.

Click Create. The destination becomes active straight away and starts receiving matching events.

The Webhooks tab lists every destination with its Destination (name and description), Endpoint URL, Events (first few tags plus a +n count), Status (for example, Active) and Created On date. Use the copy icon to copy the full URL, the pencil to edit, and the bin icon to delete a destination.

Webhook Logs

On the Webhooks page, switch to the Logs tab to see every delivery attempt Kickcall has made to your endpoints. Use the date range picker at the top right to narrow the period, and paginate through results with the records-per-page control.

Column	Purpose	Example
Status	The HTTP response code your endpoint returned	Green (e.g. 201) = delivered; red (e.g. 422) = your endpoint rejected or failed to process the payload
Webhook	The destination name the event was sent to	Acme CRM
Event	Which event triggered the delivery	call.ended
Attempts	How many times Kickcall tried to deliver this event	More than one attempt means earlier tries did not return a success response
Action	The eye icon opens the delivery detail	Inspect exactly what was sent and what came back

Note: Logs are the fastest way to debug an integration. If your system is missing data, check here first — the status code tells you whether the problem is on Kickcall's side or in your endpoint.

Expected result

Your webhook destination appears in the list and starts receiving matching events immediately.
Webhook Logs show successful (green) deliveries for each subscribed event.

Verify the result

Trigger a subscribed event (for example, place a test call that the agent answers) and confirm a matching entry appears in Logs with a green status code.
Open the delivery detail with the eye icon and confirm your endpoint received the expected payload.
Confirm the event data arrived in your own system (CRM record, dashboard update, or workflow run).

Troubleshooting

Problem or Symptom	Likely Cause	Solution
Red status codes in Logs (e.g. 422)	Your endpoint received the request but rejected the payload — usually a validation error on your side	Open the delivery detail with the eye icon to see the exact payload and response, then fix validation on your endpoint
Multiple attempts for one event	Earlier deliveries did not return a success response — your endpoint may be down or slow	Check your endpoint's availability; Kickcall retries delivery automatically
No deliveries at all	Wrong event selection, or the event has not occurred yet	Edit the destination (pencil icon) and confirm the event checkboxes; trigger a test event

Recovery or rollback

Wrong webhook configuration: click the pencil icon to edit the endpoint URL, name, description, and event selection. Changes apply to future deliveries only.
Deleting a webhook: stops all future deliveries. Existing log entries remain available for the retained period so you can still audit what was sent.

Frequently Asked Questions

What is the difference between Webhooks and API Keys?

Webhooks push events to you as they happen. API Keys let your systems call Kickcall on demand. Most integrations use both.

What happens if my endpoint is down?

Kickcall retries the delivery. The Attempts column in Logs shows how many tries were made, and the status code of each attempt tells you why it failed.

Why do I see a 422 in the logs?

A 422 means your endpoint received the request but rejected the payload — usually a validation error on your side. Open the delivery detail with the eye icon to see the exact payload and response.

Can I change the events on an existing webhook?

Yes. Click the pencil icon on the destination row to edit the endpoint URL, name, description, and event selection. Changes apply to future deliveries only.

Must my endpoint be HTTPS?

Yes. Endpoints must be publicly reachable over HTTPS so payloads are encrypted in transit.

API Keys — Authenticate Your Systems with Kickcall
Configuration — Set Up and Run Your Whitelabel Platform
My Integrations

Was this helpful?

Still need help? Ask the team