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?
You may also like
Is it time to change the governance of WebRTC in order to keep it growing and flourishing?
Read More
RTC@Scale is Facebook’s virtual WebRTC event, covering current and future topics. Here’s the summary for RTC@Scale 2024 so you can pick and choose the relevant ones for you.
Read More