The basic mechanism: a platform-initiated HTTP request
A webhook works in the opposite direction from a typical API call: instead of your system sending a request to the platform to ask a question, the platform sends a request to a URL you registered in advance, whenever a specific event you subscribed to occurs. The payload of that request typically describes what happened — the event type, the relevant identifiers, and a timestamp — so your system can react to it without needing to separately look up the details.
Why this matters specifically in a contact center
Call and conversation state in a contact center can change multiple times within seconds — ringing, connected, on hold, transferred, completed — and a downstream system (a CRM, a workforce-management tool, a reporting dashboard) that needs to reflect that state accurately benefits from being told the moment it changes, rather than discovering it on the next scheduled check. A CRM screen-pop, for example, is only useful if it appears close to the moment a call connects, not minutes later.
The alternative: polling
Without webhooks, a downstream system has to poll — repeatedly call an API on a fixed interval and check whether anything has changed since the last check. Polling is simpler to implement but introduces latency (a change waits up to a full polling interval to be noticed) and can miss fast-moving intermediate states entirely if the interval is longer than the time a given state persists.
What a well-designed webhook needs beyond just sending a notification
A production-grade webhook implementation needs more than firing a request and hoping it arrives: validating the event payload against a defined schema so malformed data doesn’t silently corrupt the receiving system, retrying delivery if the receiving endpoint is temporarily unreachable, routing events that continue to fail after retries to a dead-letter path so the failure is visible rather than silently dropped, and giving the receiving system enough information to recognize and ignore a duplicate delivery (idempotency) if a retry results in the event arriving twice.
Can the vendor tell you — in one sentence — which of their AI capabilities are rule-based, which are generative, and which are still roadmap?