by Gautam Hazari
The ‘A’ Revolution: AI, APIs, and the Future of Digital Innovation
Is it just a coincidence that almost all things discussed in the digital world converge into the first letter of the English alphabet – “A”, that is? Just few months back, we returned from the annual connectivity and technology pilgrimage to Mobile World Congress.
Most of the discussions were around ‘A’s – AI [am I surprised?] (including all the other ‘A’s around AI – Agentic AI, AI Agents, Autonomous robots, etc.) and APIs (Network APIs to be more precise).
APIs are interesting, especially in the context of telecoms. They promote openness and reaching out to the overall Internet and the extended digital world, as APIs are the language with which machines interact.
Interestingly, APIs are not new—the first API specification was written even before the term “API” was invented.
British computer scientists Maurice Wilkes and David Wheeler worked on the EDSAC (Electronic Delay Storage Automatic Calculator), an early version of the John von Neumann-inspired computer, at the University of Cambridge during the 1940s.
They were working on the modular subroutines for EDSAC. At the time, computers were on an amazing journey, and the subroutines were stored on punched paper tapes. Wilkes and Wheeler created “notes” on how to use those subroutines—the first “specification” of some sort, in the form of a catalogue.
This specification was published in the book by Wilkes and Wheeler – “Programs for an electronic digital computer”
Two decades later, in 1968, Ira W. Cotton and Frank S. Greatorex presented the paper: “Data structures and techniques for remote computer graphics” at the AFIPS conference (American Federation of Information Processing Societies), where the term API was coined, although it meant “Application Program Interface” instead of the current meaning of “Application Programming Interface”:
A few years later, in 1974, C J Date, whom I followed with keen interest for all the relational database work he did, published the paper: “The Relational and Network Approaches: Comparison of the Application Programming Interface”
And the term API, with its current form “Application Programming Interface”, saw the light of day, although in this paper, it was in the context of relational databases. A decade and a half later, in 1990, the more general definition of API was introduced by the Author and Technologist Carl Malamud as: “… a set of services available to a programmer for performing certain tasks”. The API revolution was started, fuelled by many frequent events, and it continues to date.
APIs are the fuel for innovation, the Network APIs initiatives from the Telecom industry are a critical strategy for enabling innovation by opening and exposing the assets, services and signals from the Telecom operators, and creating an additional revenue source, creating a win-win scenario.
As per GSMA, the estimated B2B Open Gateway Market with Network API is to reach $400 billion, and the Antifraud APIs market is to be $252.7 billion on top of this, as estimated by Allied Market Research.
Akamai reported that 83% of all web traffic comes from some form of API. As per ProgrammableWeb, there are 24000+ public APIs listed in their directory; many more private APIs exist in the digital world, making a significant impact in the overall technological acceleration we see today.
Statista reported that developers spend 30% of their time coding APIs of some form. This is almost double the time they spend debugging the code, which is 17%, the second most time-consuming task for developers.
APIs have evolved several times, from SOAP-based APIs to RESTful (I still remember the heated and emotional debates on SOAP vs. RESTful while working on large-scale API exposure systems for Telecoms) and from service-oriented APIs to data-oriented APIS.
Like anything else in the digital world, APIs are also evolving. I can see a specific trend in synergy with the rest of the digital world and broadly with the technological world. Here is what I see as the evolution of APIs so far, especially for the APIs in the context of Network APIs, although it applies generally to any other domain as well:
Stage 1: Siloed – Service-specific, Vertical APIs
This is a service-based approach, where each of the services has a set of APIs, either structured through “resources” to follow a RESTful model or a specific API per service
Stage 2: Singular – Horizontal APIs
A convergence of APIs into a singularity – a single API across services irrespective of geography and functionality, a singularity across space and time (the API remains the same across availability and coverage and also does not change for future products and coverage)
Stage 3: Convergent – across device and server-initiated APIs
Most APIs are positioned between servers, initiated by the API consumer’s server and fulfilled by the server of the API provider. Devices initiate some APIs due to the functional boundaries, e.g., Mobile Authentication APIs, which need the mobile device to interact with the mobile network.
Earlier, the server-initiated and device-initiated APIs were two separate entities, and now, as with everything else, there is a convergence on the horizon, converging the device and server-initiated APIs as much as practically feasible and adding the device-initiated part as a logical extension.
Stage 4: BYOA – Bring Your Own API
The API as a language and the technical contract have been one-sided for most of the time it has existed – it is defined and enforced by the provider of the API, and in a way, this makes sense. If we now bring in the business expectations and customer centricity, in certain situations, why can’t the API consumer expect the API or at least some part of it to be defined by the API consumer?
This is an interesting aspect of the evolution of APIs. It breaks the inertia of the API ecosystem’s one-sidedness and allows API consumers to bring in their own API definitions, at least part of them, under certain conditions and constraints.
Stage 5: Humanisation of APIs – Natural language-based APIs:
This is the ultimate convergence, and my favourite one: the convergence of the language of machines and that of humans. With the advancement of Generative AI and large language models—from text only to multi-modal and from closed to open source—the language barriers between machines and humans have become very thin, if not completely invisible.
This has given us the opportunity to go way beyond the discussions of one-sidedness of API definitions or what API specifications to use, the APIs will be accessed using natural languages.
Generative AI and large language models will make machines use the same natural language as humans, humanising the APIs and redefining the ultimate singularity.
At Sekura.id, the SAFr APIs are at the ultimate edge of API evolution, and the Uniti platform is leading and already in pole position for the Network API ecosystem.
The future is magical; the future is now at Sekura.id
Gautam Hazari is the Chief Technology Officer at Sekura.id and one of the foremost authorities in the field of mobile identity, authentication, and telecom-grade API innovation. With over two decades of experience in engineering, architecture, and digital identity systems, Gautam has helped shape industry standards for mobile authentication, including his foundational work on the original GSMA Mobile Identity APIs. A frequent keynote speaker and thought leader, Gautam is known for bridging deep technical expertise with strategic vision—driving real-world impact across fintech, telecoms, and security sectors.
