The new Voxbone API (v3.1) is live since June (06/2014). It’s been a very interesting experience to work on this new release because the API is key to Voxbone’s vision to simplify telecommunication services. Voxbone’s API allows the ordering and provisioning of services in real-time, including DID numbers, SIP trunk capacity, Fax, SMS, etc.

Although Voxbone also provides a portal to its customers’ operational teams, the API gives a lot more automation, flexibility and innovation power.

We have seen a lot of developments in the last couple of years around telco APIs. Telecom operators, especially in the mobile space, are starting to realize that their infrastructure and user data (user profiles, behaviours and preferences, location data, etc.) are assets that can be exposed to third party application developers. They are also betting on the boom of machine-to-machine and connected devices. According to Gartner, there will be nearly 26 billion devices on the Internet of Things by 2020 ( These devices will also be more capable. They will be able to do a lot more things (flying, smelling, hearing, seeing, measuring temperature, etc.). It means that the combination of these devices’ capabilities with multiple online services (also known as mashups) are endless. APIs makes it all possible and simpler.

Voxbone’s API is currently focused on service provisioning, allowing our customers to order and manage their services via the API rather than having to do it manually on our portal or contacting us directly by email or phone. For example, a unified communication provider (Voxbone is Lync certified) can automate some of their internal processes for their new customers. Is there enough capacity to add a new customer? If not, the API automatically facilitates the ordering of additional capacity. Is Fax required? The API then automatically configures the Fax service. This means that it ends up saving time and resources for our customers which can instead focus their resources on improving customer service and quality.

We have gathered a lot of feedback during the six months beta (v3.0). We are now planning to release a new version of the API (v3.2) which will include porting capabilities. Our API roadmap is defined with the following elements in mind:

  1.  The API must be comprehensive and expose all Voxbone services – The version 3 of the API is already much more comprehensive than version 2, with the support of XML/SOAP, XML or JSON/REST,  SMS configuration, Fax configuration, trunk capacity ordering, etc. Soon, we will add WebRTC and Porting (planned in v3.2). VoxOUT (Emergency services), CNAM or an improved CDR browser which are existing on the web portal will be added to the API later. So a lot of existing portal services will be ported to the API. But we are also looking at adding new services. We  also value our customers’ feedback and use this to build our product backlog. This is the frustrating bit for me as a product manager who would like the entire backlog implemented, and has to go through the challenging process of prioritization… However, it is rewarding when new ideas influenced by our customers are delivered. For example, we are considering number search and selection, callback methods and a lot of other small improvements for 2015. The next move will probably be to extend the API to services that are different from provisioning (or ordering): sending/receiving SMS, exposing call quality metrics, etc.
  2.  The API must be suitable and optimized for different use cases and call flows – We have realized that it’s not enough to just expose resources. The way they are exposed is also important. Sometimes our customers have very specific needs for which our API calls are not optimized. For example, we have changed the way the ordering is done, adding a “cart” service. This is a solution that some of our customers love, but some others would rather bypass the cart and just place the order as this is quicker in their specific call flow. The address regulation process is also another area which we would like to improve.
  3.  The API must be robust and scalable – Our API services have a track record for reliability with close to zero downtime since its first version. We want our API to be outstanding to reflect the importance of quality for Voxbone. The optimization of the calls with significantly lower response times (which are currently comparable to the previous version) is one of the things on which we will be working on.
  4.  The API must be easy to implement – We are testing different tools to properly manage documentation and build a developer community. One of the basic requirements is that the documentation must be up to date. This is especially important because the API changes on a regular basis. Voxbone delivers minor releases once a week and major releases once a month. This means that impacting changes can happen once or twice a year at the API level. When these changes happen, we want our customers to be informed and the documentation updated automatically. A developer community manager (Sacha Nacar – you can contact him on snacar at Voxbone) has joined the team and will help improve the resources that are made available to our customers. More code samples in different programming languages will be provided, so that the API integration is made easier and shorter. Finally, our support team must be continuously trained so that they can provide the right level of support in various domains.

To conclude, I encourage our customers to have a go with our new API. The ROI is clear and makes it a simple choice. We have seen customers being able to scale up and have impressive growth without increasing their operation teams. This is because they were able to automate most of their processes thanks to our API. I advise to start with a few easy things to implement such as  browsing the inventory and automating some DID configurations. There is no need to go directly for the more complex processes like address regulation (but if that’s what you want, we will be there to guide you). For our customers who are using the version 2, I recommend to start working on a migration plan from version 2 to version 3 as soon as possible. Sacha (our Developer Community Manager) can help you. The plan is to end support and maintenance on v2 by March 2015. The API v2 service will be stopped in March 2016.  Meanwhile, we will continue to add some new features to version 3 – make sure to stay tuned!