A webhook is an automated message that one system sends to another system’s web address when something happens. Instead of your application repeatedly asking a provider “anything new?”, the provider sends an HTTP request to a URL you specify as soon as an event occurs: a customer replies to a text, a message is delivered, a call is answered or a recording is ready. Webhooks are how communications platforms, payment services, software-as-a-service tools and many other systems tell your software about events in near real time.
At a glance
- A webhook is an HTTP request a service sends to your web address when an event happens.
- It reverses the usual API pattern: the provider contacts you, instead of you polling the provider.
- In CPaaS, webhooks commonly carry inbound messages, delivery reports and call events, and in programmable voice can ask your application what to do next on a call.
- Your endpoint must be reachable, respond quickly and handle repeated or out-of-order events.
- Many providers sign webhooks so you can verify they are genuine; methods vary by provider.
What problem it solves
Software often needs to react to something that happens elsewhere. When a customer replies STOP to a text, your system should record the opt-out immediately. When a message fails, your support team may need to know. When a call ends, the CRM should log it. Without webhooks, your application would have to keep calling the provider’s API to check for changes, which is slow, wasteful and can hit rate limits.
Webhooks push the information to you instead. The provider sends each event as it happens, so your systems stay up to date without constant polling. For communications platforms, webhooks are often the main way inbound traffic reaches you: on many platforms, a reply to your business number reaches your application as a webhook, although some also offer API polling, message logs or event streams.
How it works
Registration. You give the provider a URL for your endpoint, usually per account, phone number or application, and sometimes choose which event types to receive.
Delivery. When an event happens, the provider sends an HTTP request, commonly a POST, to that URL. The request carries event details such as the message text, sender and recipient, delivery status, call status, timestamps and identifiers, typically as form data or JSON.
Response. Your endpoint processes the event and returns a success status code. In programmable voice, the response can also contain instructions, such as play a message or connect the call to another number, which is how many platforms let software control calls.
Retries and duplicates. If your endpoint fails or is slow to respond, many providers retry for a period. Retry policies vary by provider, and some events can arrive more than once or out of order. Well-built receivers record event IDs to ignore duplicates and avoid assuming order.
Security. Your endpoint is a public web address, so anyone who finds it could send it fake events. Common protections include HTTPS, verifying a signature the provider adds to each request, checking timestamps to reject replays, and limiting where requests can come from. Endpoints that receive webhooks are web-facing interfaces like any other, and web application and API protection controls can help, provided they are tuned so they don’t block legitimate provider traffic.
Where events go next. Many teams pass webhook events into a queue, a microservices architecture or an integration tool, then on to a CRM, help desk or data warehouse.
For buying guidance on platforms that rely heavily on webhooks, see our communications platform as a service solution page.
When it matters for buyers
- Adopting a CPaaS or SMS gateway. Inbound messages, delivery reports and call events usually arrive by webhook, so you need an endpoint ready before launch.
- Opt-outs and compliance records. Missed or delayed webhooks can mean missed opt-out requests or gaps in records.
- Integrating SaaS tools. Many business applications use webhooks to notify each other, which can replace scheduled data syncs.
- Security reviews. Unverified webhook endpoints can accept forged events; reviewers will ask how you authenticate them.
- Reliability planning. If your endpoint goes down, events may be retried, delayed or lost depending on the provider.
Questions to ask vendors
- Which events can you send by webhook, and can we choose which ones we receive?
- How do you sign webhook requests, and how do we verify them?
- What is your retry policy, and can we see or replay failed deliveries?
- Can events arrive more than once or out of order, and which identifiers should we use to handle that?
- What timeout do you apply to our responses, and what happens to a live call if our endpoint doesn’t answer?
- Can we set a fallback URL if our primary endpoint is unavailable?
- Which source addresses or networks do webhooks come from, if you publish them?
How it differs from API polling
With polling, your system calls a provider’s API on a schedule to ask whether anything has changed. It is simple to build but adds delay between checks, uses requests even when nothing has changed and can run into rate limits. A webhook reverses the direction: the provider calls your endpoint when an event happens. Webhooks are usually faster and more efficient, but you have to run a reachable, secure endpoint and handle retries. Many teams use both, relying on webhooks for real-time events and running a periodic API check to catch anything missed.