Telco API providers come in different shapes and sizes – and they might not even be carriers.
Ever wanted to send an SMS in an automated fashion? Or get a phone number configured to forward incoming calls remotely? How about getting information about the location of a phone? All these may be considered as Telco APIs, and there are different types of vendors supplying them.
OneAPI, from a Carrier (or an Exchange)
The GSMA, a standardization organization for carriers, have published a couple of years ago a set of standardized APIs. It called them OneAPI. This API set includes access to location, payment, identity, SMS and various other capabilities.
These APIs are designed to be provided by carriers, but in some ways they are rather limiting. I guess this is the old syndrome of “design by committee” that exist in most standardization organizations.
As stated on the GSMA’s website:
As of February 2013, there were five major operator groups (AT&T, Deutsche Telekom, Orange, Telefonica and Vodafone) participating in the OneAPI Exchange solution
In addition to this, three Canadian operators, Rogers, Bell Mobility and TELUS have commercially launched APIs on the respective OneAPI Gateway platform. GSMA OneAPI Gateway
Not a large coverage, especially if you consider that most (all?) of the operators indicated in the statement also have other means of exposing APIs.
In a way, there’s an attempt here for something that developers can use and run against any carrier in the world, but it didn’t really caught on.
“Proprietary” API from a Carrier
Carriers also provide their own proprietary APIs. These offer some interesting capabilities, but they will probably be available on that carrier only or have a different API signature (and hence different implementation to integrate with) when provided by another carrier.
A nice example of this? What Orange’s rich profile information:
The Rich Profile API allows your website to automatically access and retrieve around thirty profile attributes such as email, photo, address, interests for Orange customers registered on www.orange.fr.
This is a solution for local players who wish to use APIs to access a specific target population of that specific carrier who offers that API.
“De-facto” API from a Carrier
There are now quite a few vendors who provide Telco APIs – mainly in the Communication API domain. Some of them come with large developer ecosystems already, which makes them a “de-facto” standard in a way.
Some of these vendors have focused on partnering with carriers and working with them directly in business models and technology architectures that work well with carriers. The poster child here is probably Tropo, who are being used today by AT&T and Deutsche Telekom among others.
Such APIs have the fragrance and flavor of a standard that can be use across carriers, so there’s no local lock-in involved in using them.
“De-facto” API from a Vendor
You can get the de-facto APIs from a vendor instead of a carrier as well, and when necessary, connect to a carrier’s network. Poster child here? Most probably Twilio.
In this case, you don’t need to be thinking about which carrier at all, as your only business connection is with the API vendor.
“Proprietary” API from an Aggregator
There are aggregator vendors. These are companies that take a specific API – usually SMS – and provide an easy API for it, taking care of the hassles of working out the integration points with carriers around the globe. Here you will find vendors like SMSGlobal and many others.
The difference between these and the “De-facto” group? In my mind it is the focus.
“De-facto” solutions look at carriers as their partners or customers and the developers as the drivers of the ecosystem. The aggregators look at carriers as suppliers and developers as customers – there’s no effort or need to build an ecosystem – just to offer an arbitration point between the carrier and the developer.
That’s not to say that aggregation of APIs isn’t a viable business – it most certainly is.
Smartphone OS API
You can access a lot of the functionality that exist in Telco APIs directly on the phone (if it is a smartphone running a modern mobile OS). Sending SMS or controlling incoming calls? You can do it on Android and iOS. Same for location information, and many other capabilities.
While limited to a specific OS, this might be a large enough audience, and it doesn’t really focus or lock you in to a region. Works at times, but not suitable in some cases.
Telco API that… isn’t a Telco API
Searching for some speech to text or text to speech API? Search no more… AT&T has Watson APIs for you. It has nothing real to do with carriers – I guess it is an internal technology they had and just decided to open it up for developers to see what happens.
There may be other such example out there, which aren’t really Telco APIs but are provided (or can be provided) by telcos.
–
Did I miss anyone?
There’s also Apidaze 🙂
Yap.
For all those who I forgot to mention: this post doesn’t indend to provide any opinion on my part who is the best of breed or the only player in a given domain – vendors and carriers mentioned are simply widely known examples to make a point. There are many additional vendors out there offering solutions in this domain – feel free to contact me if you want me to learn more about your offering.
Hi Tsahi,
Regarding telecom APIs, I would also make the distinction between bundled and unbundled APIs,
Bundled APIs are the ones that are pre-integrated with a selection of carrier(s). Both of your categories above – “API from vendor” and “API from carrier” – fit in the bundled category. The business model is then a combined price for the API transaction and the telecom service.
Recently we’ve also seen unbundled offers, where the API is independent of the telecom service by companies such as Shango or Plivo. This is also called “Bring Your Own Carrier” (BYOC). It gives users the added flexibility of selecting their carrier, for example a SIP trunking provider, and connecting it into the API platform. In this case there are 2 separate business models – one for API transactions and one for the SIP trunking service.
Both are interesting in that they serve different types of users.
In my opinion, what’s key with all the API platforms, is that they provide challengers with instant access to a *global* infrastructure. Essentially it allows cloud start-ups to compete against global telcos as it lowers the barrier to entry.
Itay Rosenfeld
CEO
http://www.voxbone.com
Hi,
I come cross to this article via Google search. I have a question here, how does voice API interconnect with Telco? the voice connection eventually need bypass the telcos infrastructure.
Not sure I understand the question 🙁
Small businesses and startups usually do not have the budget to compete with big players in their industry in terms of advertising and marketing. Mass texting levels the playing field with cost-effective business communication that allows them to build relationships, expand their operations and grow in revenue.
Mass texting equates to spam. Personalized is something else.
In 2019 and beyond, businesses big and small need to think how to personalized and engage with their customers and not how to send yet another spam message to them.