Glossary
What is Webhook?
Also known as: HTTP callback, web callback
A webhook is an HTTP callback — one application sending a real-time HTTP POST request to another when a defined event happens. Where polling has the receiver repeatedly ask "anything new?", a webhook has the sender push the event the moment it occurs. Webhooks are how most modern SaaS integrations connect, and how most law-firm intake pipelines pass calls, contacts, and matters between CallRail, GoHighLevel, Clio, and AI voice agents.
How a webhook works
In a webhook setup, the receiving application registers a URL with the sending application and tells it which events to notify on. When one of those events occurs, the sending application makes an HTTP POST to the registered URL with a JSON payload describing the event. The receiver returns a 2xx response to acknowledge; if it doesn’t, most senders will retry with backoff.
A typical law-firm flow: CallRail receives a call and sends a webhook to your CRM (GoHighLevel) with the caller’s number, tracking number, and call recording URL. GHL processes the webhook, creates or updates a contact, and may send its own webhook downstream to your AI voice agent or n8n workflow.
Webhooks vs. polling vs. real-time APIs
Polling has the receiver call an API on a schedule asking "what’s new since last time?" — simple but high-latency and wasteful at low event rates. Webhooks have the sender push events as they happen — low latency and efficient at low rates, but the receiver has to be reachable and the security model is more complex (signature verification, IP allowlisting). Real-time APIs (WebSockets, SSE, gRPC streaming) keep an open connection — best for very high event rates or bidirectional traffic, but operationally heavier than webhooks.
For most legal-tech integrations, webhooks are the right default. CallRail → GHL → Clio runs on webhooks. AI voice agents typically invoke tool calls via webhooks to your CRM and practice management system.
Common webhook gotchas
Three things bite teams new to webhooks. (1) Idempotency — webhooks can be delivered more than once during retries. The receiver needs to handle duplicate events (typically by checking an event ID and skipping repeats). (2) Signature verification — anyone who knows the URL can POST to it. Production webhooks should verify a signature header to confirm the request actually came from the expected sender. (3) Failure handling — if the receiver is down when a webhook arrives, the event is lost unless the sender retries (most do, with limits). Building a small queue or buffer between webhook receipt and downstream processing is wise.