By Simon Woodhead
OK, so webhooks aren’t completely new – we’ve had them for certain API functions, notably incoming fax and SMS, and we significantly upgraded the backend for these in 2018. Today we’re putting that backend to massively more use.
TLDR: web developers are significantly cheaper and more available than SIP application developers, and you can now build many things simply by presenting us with a web endpoint.
We’ve hooked into numerous areas of the Simwood stack, to generate events, which are pushed to you on a predefined end-point. These are for administrative things such as updated rates but most excitingly the following:
- Inbound calls – get events for new inbound calls, with updates as call state changes
- Outbound calls – get events for new outbound calls, with updates as call state changes
- Blocked calls – get notified of blocked calls due to account limits or fraud settings (this is distinct to the existing http endpoint for notifications)
- CDRs – get CDRs pushed to you as calls are billed
We have a number of other options in the pipeline, but already with these we think you can build some special things through real-time call status, out of band. A number of you offer call-tracking by hooking either into CDRs or through your own custom logic around the SIP dialog. Now, you can do this much more simply – leave the SIP to do its thing, and instead perform live call tracking by way of a web application processing real-time events, trivially even indicating call status to your customers.
We know some customers struggle with SIP traces and we sometimes see support tickets about ‘calls not arriving’. We know they are and a SIP trace confirms customer equipment is rejecting them, but at the level the reporter is working the calls are not visible. Webhooks could therefore be used to trivially monitor the calls that were coming in, and the status of them, so you could know very quickly if you were rejecting traffic, and expose this to a lower technical level in your support team.
Similarly, CDRs have always been a bugbear. We could do them the Neanderthal way and give you a CSV the day after the fact, and certainly some people would like the uniformity with other providers. However, we prefer to give you real-time access, not least for your own efficiency of billing, but also fraud control. Managing the reality of certain people requesting every CDR ever, several times a second, is a consequence of this we’ve had to manage over the years. Making them eventually consistent, and out of band with actual billing has been the optimum solution, but is not without consequence – by virtue of being out of band and eventually consistent. Now, we’re able to generate webhooks in-band with our billing routines, so you should get CDR webhooks even faster and more consistently than polling the API.
We’re releasing this in beta now, so don’t dispose of legacy / backup solutions just yet – you need those for reconciliation at least or failover potentially, but this is an exciting direction of travel and we’re very excited to hear any ideas you have.
This feature is configurable through the portal but we’ve held off releasing that on a Friday night. You can find the docs here. Fire us a support ticket with the application and endpoint, and our operations ninjas will enable them during normal support hours. The portal feature will be released on Monday (this post is being published on a Friday evening!).
