What Is a Webhook?

What a Webhook actually is

The word Webhook is made of two English words: Web, and Hook, a "catch point." The idea is simple: you give the PBX an address on the internet, and it commits to "knock on the door" of that address every time an event happens that you asked to know about.

Think of it like a courier delivering a letter. Instead of going out to the mailbox every five minutes to check whether anything arrived, the courier rings your doorbell the moment there is a letter. The letter is the "event details," for example which number called, to which line, and when. The door is your server, or a system such as a CRM, which receives the message and does something with it.

In technical terms it is sometimes also called an HTTP callback, because the message is sent using the protocol of websites (HTTP), and it "calls back" to your system.

How it works — step by step

1. You set up an address. Someone on your side (a developer, your CRM vendor, or us) prepares an internet address that knows how to receive messages, for example an address on the server of your order system.
2. You connect it to an event. In the PBX you set when to call the address: when a call comes in to a certain line, when it reaches a certain point in the route, and so on.
3. The event happens. A customer calls. At that moment the PBX sends a request to the address, with details inside: the caller's number, the call ID, the line that was dialed.
4. Your server processes it. It looks up the number in the customer list, opens a record, logs the call or sends a message to an agent.
5. The server replies. A short answer goes back to the PBX. In some cases the reply even affects how the call continues, for example where to transfer it.

All of this usually takes a fraction of a second. The agent can see the customer's record even before picking up the handset.

What is inside the message

The message the PBX sends is a regular web request, usually of the POST type, with fields and values inside, like a website form that fills itself in automatically. Common fields in phone systems: the caller's number, the number that was dialed, a unique ID for the call, the time, and sometimes also the point in the route where the call currently is.

The unique call ID is especially important. With it, your system can connect the message it just received with the full call record it will pull later, and make sure it didn't log the same call twice.

The reply from your server is also part of the contract. Some systems are satisfied with "received," and in others the reply tells the PBX what to do next: which menu to continue to, or which agent to connect. So it is important to know in advance exactly what format to reply in.

Webhook vs. API: who asks whom

The other way to connect systems is an API. The difference is the direction: with an API, your system contacts the PBX and asks "what's new?" With a Webhook, the PBX contacts you and tells you. The first method is called "Polling," the second "Push."

In practice, good systems combine both. The Webhook announces "new call from this number," and after the call ends the system uses the API to pull the full call record: duration, who answered, recording.

Real-life examples

• A store in Bnei Brak: when a customer calls, the order system receives the number and shows the agent the customer's latest order. The agent answers, "Hello, about yesterday's order?"
• A yeshiva with a dormitory: every call to the parents' line is logged automatically in a spreadsheet, so the dorm supervisor sees who called and at what time.
• A nonprofit on a fundraising night: every call coming in to the donations line updates a counter on a screen in the room, and the volunteers see the progress in real time.
• A service center: a call that wasn't answered opens a "call the customer back" task in the management system, with the customer's name and the time of the call.
• An appointment system for a doctor or advisor: the caller is identified, and the system decides, based on their record, which agent to route them to.

What to check before connecting

• The server must answer fast. The PBX waits for the reply while the call is waiting. A slow server means a caller waiting in silence. It is better to do the heavy work after replying.
• A direct reply, no redirects. Many phone systems do not "follow" a redirect to another address (Redirect), for security reasons. The address must be the final address and reply directly.
• Know what happens when the server goes down. What will the caller get if the address doesn't answer? It is worth planning a fallback route, so the call continues even if the external system is unavailable.
• Security. The address is open to the internet, so make sure it accepts only genuine requests and does not expose information to someone who simply guessed it.
• Test with a real call. Before connecting the main line, try it on a side number and make sure the details arrive in exactly the format the system expects.

Advantages and Limitations

The big advantage is speed: the information arrives the moment the event happens, with no delay and no load from repeated checks. The second advantage is simplicity: there is no need for software that runs all the time asking; a server that listens is enough.

The limit is that you need a second side that is ready to receive: an address open on the internet, working all the time. A Webhook also does not replace history. If your server was down for an hour, the messages from that hour will not always "wait" for it. So you fill in the picture from the call log through the API.

Three real-life connections, step by step

1. A customer record that pops up at a clinic. A clinic with its own appointment system. The Webhook is connected to the point in the route where the call reaches the reception desk. When a customer calls, the PBX sends the appointment system the caller's number, the call ID and the time. The appointment system's server looks up the number, finds the record, and shows the receptionist a window on her screen: the name, the next appointment, notes. It replies "received" to the PBX in under a second, and the call keeps ringing. If the number isn't found, a "new customer" window opens with the number already filled in. If the clinic's server is down, the PBX doesn't wait for it; the call rings as usual, just without the window.

2. An unanswered call becomes a task. A service center of an air conditioning company. A Webhook on call end in the service queue. When the call ends, the PBX sends the call ID and what is known: the number, how long they waited, whether it was answered. If it wasn't answered, the management system's server opens a task "call back 052-XXXXXXX, waited 3 minutes" and assigns it to the available agent. At the same time an SMS goes out to the customer: "We saw that you called, we'll get back to you within an hour." Half an hour later, when the recording is ready, the system uses the API with the same ID and pulls the full call record into the task.

3. A live board on a fundraising night. A nonprofit with a donations line and a queue of thirty volunteers. A Webhook on entering the queue and on call end. A small server (even a laptop in the room) receives the messages and updates a page projected on the wall: how many calls came in, how many are waiting now, how many were answered in the last ten minutes. When the number waiting goes above five, the page turns red and the coordinator calls in more volunteers. There are no customer records here and no complicated system, just counting. Still, it is the tool that lets the coordinator run the evening instead of guessing.

When to use a Webhook and when to ask: by scenario

The last row is important: a Webhook requires an address the PBX can reach. A computer in the office behind a regular router is not one, unless you open a path to it or use an intermediate service.

What to agree on with the developer before starting

One page, six lines, and you save a week of "why isn't this working":

1. The address: a final, secure address (HTTPS), with no redirects.
2. When it is called: at which point in the route: entering the line, entering the queue, end of call.
3. What arrives: the list of fields and their exact names, including the call ID.
4. What you reply: "received" only, or a reply that affects the route, and in what format.
5. How long: the server replies within a second; the heavy processing happens after the reply.
6. A test number: a side number to try on before touching the main line.

And one more line worth adding: what happens when the server doesn't answer. The route continues without the window, rather than a call getting stuck.

Common mistakes when connecting a Webhook

• Working first and replying later. The server searches for the customer in three databases and only then replies. Meanwhile the caller waits. Reply "received" immediately, and search afterward.
• Identifying a call by the caller's number. The same customer calls twice on the same day, and the system logs one. The call's unique ID is the key, not the number.
• Testing on the main line. One mistake in the format, and all of the morning's calls go through without the window. Try it on a side number.
• Changing an address on the server and forgetting the control panel. The developer moved the server, and the PBX still calls the old address. Every address change means an update in the Webhooks screen.
• Relying on the Webhook as a log. The server was down for an hour, and an hour of events is missing. Fill it in from the call log.