GSMA 3rd Party Access initiative – API enabing the network operator


I have long talked about Operators allowing third party access to network APIs. This ‘holy grail’ for developers has come closer one step with the GSMA 3rd Party Access (Access) initiative which aims to identify and provide means for 3rd parties to more effectively and efficiently utilise operator network and service capabilities

I think this is truly a positive step and Kevin Smith (Vodafone)/GSMA & Graham Trickey (Technical Director GSMA) have been kind enough to keep me updated about this initiative.

I think this is a positive step and I fully endorse it(just as I have historically supported other pragmatic Operator led initiatives like Vodafone Betavine. So, if you are interested please comment here but also join the initiative via the link(coming soon)

In this context, 3rd parties are Web content and service providers, namely Websites and client applications that access services over HTTP. The goal is to stimulate innovation; facilitate development and deployment; and increase portability between operators. This will improve the mobile Web user experience, and hence benefit users, operators and providers.

GSMA 3rd Party Access (Access) initiative is a project run by the GSMA, supported by 10 operators with a global footprint, aims to deliver ‘sandbox’ APIs in 2008 and live implementations in 2009. The project is being run as an open Web beta, with collaboration encouraged from Web developers, network vendors, operators and aggregators. This will ensure relevance and quality of the APIs. The project will reuse parts of existing standards, documented in a way so as to be more easily used by Web developers. An SDK featuring tests, tutorials and a Wiki will be available. As well as facilitating technical portability of applications/web content, the project aims to simplify the sign-up process for smaller developers working with operators.

This initiative benefits all parties and benefits include:

a) Reducing fragmentation : Multiple proprietary APIs means only 3rd parties with sufficient resources can develop and maintain integrated applications. This creates a barrier to entry for smaller, innovative players and wastes resources at the larger 3rd parties.

b) Avoids operator dis-intermediation: A closed set of fragmented APIs has led to 3rd party frustration. As such any ‘workaround’ API that offers near-equivalent functionality is attractive to 3rd parties. Users and developers will find a way to apply services via mobile even if it means disintermediating the operator.

c) Open API in line with Mobile Web 2.0 : A common API implemented by all operators reduces the barrier to entry for mobile Web content and services. Less 3rd party time and resources are spent integrating, so more can be spent on innovating. 3rd parties benefit if time to market is reduced and new services can be launched across multiple operators through a single codebase.

d) Can complement operator developer portals : These portals aim to produce compelling applications, which is also the goal of the common API. The operator dev portals may choose to offer proprietary APIs on top of the GSMA core set, in order to differentiate their network

e) Third party access: The API allows a 3rd party to invoke a method and get a standard response from participating operators. The API must be exposed over HTTP(s), but beyond that the implementation is not prescribed: it is up to the operator to integrate into their existing gateway for network and SDP enablers. The Access API can co-exist with Proprietary APIs for incumbent partners

f) Possibility of long tail applications: Operators cannot easily predict Web innovations

…but by providing a common API, we can encourage them on the mobile Web. By reducing the barrier to 3rd party entry we reach out to The Long Tail of customers desiring niche services

And finally .. I like this analogy with the crown jewels from the GSMA ..

The APIs provide a unique customer relationship (identity, activity, billing)… …but like the real Crown Jewels, they can create revenue by being securely and publicly exposed. Hide them away, and people will go elsewhere…. Only joint commitment will ensure success and avoid fragmentation

To conclude ..

The benefit to Web Developers increases as more operators per territory adopt the API…The value to operators increases as more Web developers let us know what they want from a common API…. meaning the value of the mobile Web grows.

Please register at the project portal to contribute requirements to the APIs:

Update: As per comment from Graham Trickey below

Please note that the URL for the 3rd Party Access Portal is HERE


  1. Thank you for your comments on the GSMA 3rd Party Access project. Please note that the URL for the 3rd Party Access Portal is

  2. Ajit Jaokar says:

    Thanks Graham!Its great to get a comment from you on my blog. I have created a new post to include this link so it wont be missed. kind rgds Ajit

  3. Jyoti Narula Ranjan says:

    Thanks Ajit.
    This sure is a very good beginning.
    Of course the next step of having operators commit to implementing this set of APIs will be a more looked forward to step.
    I first read it at your blog – thanks/

  4. Ajit Jaokar says:

    Thanks Jyoti! rgds Ajit

  5. Sanhil says:

    Sounds like the idea on this site

  6. I’m still holding my firm belief that innovation of this sort does not happen at the network level, but instead at the node.

  7. Guenter says:

    For Stefan: May I ask, what you mean with “at the node”? From my perspective, web apps can benefit from information available in the network through network-side APIs and through device-side APIs. If I compare a device-resident web app (downloaded) with a Java app: the former can access device capabilities and info collected from the network via device APIs AND access network information via a server-side network API into the operator. The latter typically uses a device API (JSR) to get the info out of the device. Could we argue, the former solution is more comprehensive, more flexible?

  8. Kevin Smith says:

    Yes, the intention here is not that the API be innovative in and of itself, but rather provide easy access to more basic capabilities which help stimulate innovation. The API is intended to be accessible from the client side (widgets, XHR, native HTTP requests) as well as from the server side (bindings to Java, Ruby, Python etc.), so the aim is to be a useful part of the overall developer toolkit, and help reduce the portability problems between networks. Even if the API can only save developers time integrating, then at least they can spend more time innovating :)