Would You Use a Telco API?

April 23, 2013
There's an ongoing debate whether telecommunication companies can succeed in the API market. Here are a few pointers. If you look at how companies today are building ecosystems to drive adoption and innovation it is mainly through APIs: you take your internal resources and assets, expose them via APIs and let developers use them. Telco companies have tried doing it for years now. Alan Quayle has an interesting angle as to their attempts:
I remain amazed that Telco API standards are still considered seriously. I've just returned from a quick trip to the Bay Area were I was talking to people who lead the market in APIs, they consider the Telecom industry's perverse need to standardize APIs amusing at best and at worst yet another death knell for the industry.
Put simply, Alan Quayle is against standardization of the APIs across telecom companies. But then how can telco companies provide API interfaces at all?

The rise of the smartphone, led by Apple's App Store, shifted the developers' mindshare from telco APIs to the mobile OS APIs – you can get location from the telco, but you can just as easily get it from the phone. Same for call control, messaging and most anything else. There are sideline use cases where telco APIs can achieve much more, but not a lot need them. So if you are a telco, what's the point in exposing an API? How can you expose it without standardizing with other operators? Apple and Google each have a larger reach than any single telco in the world today. As a developer, you'd go to them instead of banking on multiple APIs of multiple telcos. And that's the thing – there needs to be some kind of standardization for the telco's APIs – something that gives developers the power to write once and use multiple telcos. How is it achieved today? By using API aggregators or a de-facto standard. Want to send an SMS? Just use someone like Open Market or any other SMS aggregator out there – use their API and run on top of multiple telco SMS platforms. These aggregators take care of it all. Apigee came up with an interesting proposition lately: a OneAPI exchange. OneAPI is a standard for Telco APIs, but it is implemented differently by different telcos, and it requires an engagement with each and every telco you wish to work with. And the benefit for developers:
A developer just picks a single operator to deal with and then builds to that operator's API, Jordan said. If the app is downloaded on a different operator's network the exchange will automatically map that carrier's API onto the app, he said.
Looking for a de-facto Telco API standard? I guess there are two of those around: Twilio and Voxeo. Twilio passed the 150K developers mark and Voxeo has 250k developers under their belt. These are large numbers for companies that essentially provide Telco APIs – either directly or with partnerships with the telcos. What are the most notable initiatives of Telcos in the domain of APIs? If you think telecom companies have a hard time in getting their APIs adopted, then think again. Netflix, a company that drives a lot of their success through their APIs, is closing up their public APIs. Kin Lane explains why APIs don't always make sense:
I would say the demise of the Netflix public API is equal part Netflix and the developer, and just the nature of the industry it exists in. […] I love and believe in APIs, but I'm not delusional enough to think they will work magically everywhere they are applied.
Telco APIs are going to be tricky to get right, and will require at the end of the day collaboration across operators. How is that achieved is a totally different story. - APIs aren't a simple matter to deal with – not as the API provider and not as the developer using the APIs. Would you be willing to use a Telco API? What do telcos need to do in order to get you hooked?

You may also like

RTC@Scale 2024 – an event summary

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