Webhooks: call events in your own system

A webhook is an HTTP request sipbox sends to your endpoint when something happens to a call. It is how telephony is wired to a system with no ready-made connector: an in-house CRM, an ERP, an internal service. Configured in the portal, included in every plan.

What people build with them

Your own customer card

Your system receives the incoming-call event and opens whatever screen matters — the order, the enquiry history, anything from your own database. No connector required.

Call records in your own database

Every conversation lands in your table or reporting system next to the rest of the customer data. Useful when call statistics belong in the shared warehouse rather than off to one side.

Alerts anywhere

A missed call can be pushed into a team chat, a tracker or an on-call system — anywhere that accepts an inbound request. There is no Telegram connector yet, but a webhook does this today.

Your own rules for missed calls

For example, automatically raising a task to call back when someone from an important segment could not get through. The rule lives in your system; sipbox only reports the fact.

How to set it up

Prepare an endpoint

You need a handler reachable over HTTPS that accepts a POST request and answers quickly. A slow response causes delivery retries, so heavy processing belongs in a background job.

Enter the address in the portal

Organisation settings hold the endpoint and the events to send there. The event list and request format are documented in the same place — we do not publish a public API reference yet, and will not pretend we do.

Verify on a real call

Place a test call and check the request arrived and parsed. If nothing shows up, write to us and we will check the logs on our side.

Worth knowing upfront

A webhook is one-way delivery of events out of sipbox. You cannot drive PBX settings through it: there is no public REST API yet.
Your handler must be reachable from the internet. A system in a closed network with no external address cannot be connected this way.
Delivery needs a live receiver: if your side is down, there is no way to replay the events you missed.
Parsing the request and matching it to your data is your developer’s job — this is integration work, not a checkbox.

Questions about webhooks

How do webhooks differ from a ready-made connector?

A connector is a finished link you simply switch on: with Bitrix24 the card and recordings reach the deal without any programming. A webhook is a raw event your side does whatever it likes with. More flexible, but it needs a developer.

Do we need a programmer?

Yes. Someone has to write the handler that accepts the request and ties it to your data. It is not a large job, but without a developer webhooks are not an option — in that case it is more honest to plan around a ready-made connector.

Which events are sent?

Events across the life of a call. The exact list and request format are in the portal settings — we do not publish a public API reference yet and will not invent one here: a specification that drifts from actual behaviour is worse than none.

Is it secure?

Requests go over HTTPS to an address you set. Treat the handler like any public endpoint: verify the source, do not trust the payload blindly and do not log more than you need — call events carry phone numbers, which are personal data.

Are webhooks included in the plan?

Yes, there is no separate charge — we bill for seats. We do not impose request quotas within any reasonable volume.

Connect your own trunk

Tell us about your setup — we’ll estimate the savings at your volume and help configure your carrier’s trunk.

Request access Talk to us