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?
- Telefonica has BlueVia and now TokBox
- AT&T has an extensive API effort, which has been recently commended by Alan Quayle
- Deutsche Telekom launched their Developer Garden last year
- The most recent one? KDDI in Japan now offers Twilio 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?
Twilio: yes, I can see how that works: lots of coverage, very simple webservice/API, but extensible, no signup, selfservice/API, pay per use, a clear website for developers.
Ticks all the right Cloud-style boxes (maybe other companies have all of this too, I wouldn’t know only had a look at the Twilio site to see what it is about).
Great overview Tsahi.
I agree that developers are unlikely to develop for one particular telco, the market is just too fragmented. And since twilio and voxeo have already solved the teleco fragmentation issue, there is no real need for them in their current form.
If telco’s want a dev ecosystem they need to define a real use case that their APIs solve that can’t be solved with existing APIs. Or at least do it better (which means federation across all telcos) and cheaper.
Kavan,
I am not that convinced. Telcos are more than SMS and voice these days.
If they provide you with an API that gives location information (not necessarily of a single user) or give you identity services – wouldn’t these be useful?
Telcos have huge assets. They might not know how to leverage them in front of developers, and that’s the problem that I see.
Hi,
Just came back from the IMS Forum WebRTC pre-workshop organized by Alan Quayle. Lots of talk about WebRTC but also around telecom APIs.
Voxeo Labs has clearly taken position as being focused on being the communications API for Telcos around the world (Germany, USA, Singapore, Philippines, other deals going on), whereas Twilio seems to be rather targeting the enterprise market, in despite of the KDDI deal.
The Deutsche Telekom “Developer Garden” seems to be the right approach with a mix of inhouse tools + external telecom APIs. So I agree with Tsahi when you state that Telcos have still a lot of resource.
Telecom API providers cannot be at the same time on multiple markets. So my guess is that we’ll end up with API providers more focused on Telcos requirements and others with a greater focus on enterprise markets.
All of this mixed with regional specificities and local providers (like apidaze.io in France, which will emerge in the next months).