Introduction

People can be forgiven for not thinking about APIs, yet we use them every day in so many different ways. From banking apps to travel updates to football scores and parcel tracking, APIs enable the flow of information that we rely on and often take for granted. They provide the unseen connectivity that allows apps, websites and services to communicate with one another to provide the services and information we ask for.

When you ask an AI to check the weather, it isn’t magic, the data is retrieved in the background using an API.

So, what is an API?

An API, or Application Programming Interface, is a defined way for one piece of software to interact with another. It sets the rules for how a request must be made and what format a response will take. In that sense, an API acts like a contract: if you send a request in the agreed format, you will receive a predictable reply.

This contract allows systems to exchange information without knowing how the other system is built. One application does not need to understand the internal workings of another, only how to speak to it through its API.

Why do APIs Matter?

Without APIs, modern digital services would exist in isolation and would be unable to share application logic or functionality over networks.

APIs make it possible for developers to build (and interact with) useful services without having to build them from scratch. For example, instead of writing their own weather forecasting service, payment system, or translation tool, developers can request that functionality from existing platforms by addressing the corresponding API endpoints of those services.

Because of this, APIs can help accelerate innovation. By using external API connectivity, developers can create a new services quicker, by connecting to existing tools and data. Large, monolithic applications that once had to contain all functionality in a single codebase are no longer usually necessary.

In this way, APIs become digital building blocks which enable application ecosystems to grow.

APIs matter because they allow systems to talk to each other, developers to build on each other’s work, and ideas to turn into working services far more quickly than would otherwise be possible.

Examples

Let’s look at a few simple examples of APIs in action. We will use basic terminal commands (in my case, on a mac) to send requests to some APIs and see the responses.

You do not need to be an expert to follow along, all you need is access to a computer which is connected to the internet, has a terminal program with the curl command available. These examples are a simple a way to show how a request can be made and how an API replies.

Agify

Agify is a curious but simple public API that guesses a person’s age based on their first name and country. It doesn’t require authentication and it is a good example of calling an API with just two parameters, in this case Name & Location.

Note: The curl command, works a bit like a very basic web browser. It sends a request to a URL and shows you what comes back. However, instead of loading a page, it displays the raw data that an endpoint (for example a website or API) provides. As an example, you can open a terminal window and type curl "https://news.bbc.co.uk" and have a look at what comes back, amongst the noise you might be able to pick out a few headlines!

Here is how we can use the curl command to make a request to the agify API:

curl "https://api.agify.io/?name=michael&country_id=GB | jq"

Note: Adding the jq command on the end helps tidy up the output and make it a bit more human readable, with the output indented and displayed over several lines.

In the above example, we’re sending an HTTP GET request to api.agify.io with 2 query parameters; “michael” and “GB”. The API will accept this as a valid request and will return the following info:

{
  "count": 23046,
  "name": "michael",
  "age": 68,
  "country_id": "GB"
}

We can see from this response that the agify API thinks that someone from Great Britain called Michael is likely to be around 68 years old.

Note: We do not know how Agify calculates this, but we really don’t need to. The point is that if we provide a name and country, the API returns a structured response.

Here is a diagram which shows (very simply) what’s happening:

Agify API request/response example (click to expand)

In this diagram, the caller (yellow box) sends the request to the agify API with specific query parameters. The API (blue box) receives it, sends it to the back-end application (grey box), and returns a structured response when it receives one from the application. This is the “contract” that was mentioned earlier, in action.

In this example, we know that to use the service, we only need to provide 2 pieces of information; name and location. The actual application logic and complexity are completely abstracted away from us. All we care about is the fact that the service is available to us when we need to call upon it.

Transport for London

Transport for London (TFL) provides a public API that shares live travel information, including Underground line statuses, disruptions, timetables and more. It is widely used by journey planning apps and travel services to keep passengers informed in real time. Unlike simple data services, it delivers operational updates that change throughout the day, making it a strong example of an API with real practical value.

Here’s how we can query it in a similar way as before:

curl "https://api.tfl.gov.uk/Line/central/Status | jq"

The above simple example will give us the service status for the central line. Whilst this simple example doesn’t require authentication, the TFL unified API does require registration and the use of an application ID and API key which would need to be included as part of real-world requests from a 3rd party application.

Note: JSON is a simple format used for sending, storing and receiving data. It represents information as key/value pairs, making it easy for both humans to read and machines to process.

Beyond Simple APIs

The examples so far have shown single-purpose APIs that return fairly simple pieces of information. They are useful demonstrations, but real world APIs rarely exist in isolation. In most organisations, there are dozens, sometimes hundreds of APIs, each handling different parts of the business such as payments, customer data, inventory, reporting, authentication and more. Some APIs are public (providing services to customers), some private and some are made available to trusted partners.

What seems straightforward at a small scale becomes quite complex when considering an entire API ecosystem.

At this point, it is no longer just about one system responding to one request, as in the Agify or TFL examples. Modern APIs live within platforms. They use gateways to control who is allowed in and how often they may be invoked. They rely on documentation and developer portals so that others know how to interact with them.

APIs require versioning and careful lifecycle management to ensure that changes do not break existing services. They are monitored and measured, not only for performance but also for cost, usage and reliability.

APIs are therefore no longer just technical interfaces. They sit within a broader operational framework and are, ideally, treated as products, used by both internal teams and external developers to build new services.

For some organisations, APIs are the primary means by which commercial value is delivered. Companies such as Stripe or Twilio offer their services primarily through APIs, turning technical capability into products.

At the same time, the landscape is changing. APIs are now being accessed not only by people or traditional applications, but increasingly by autonomous systems and AI agents. This shift brings new challenges that did not exist before.

APIs and the Age of AI

For most of their history, APIs have been used in a predictable way. A developer reads the documentation, understands the required inputs, and writes a piece of software that sends a properly formed request. The behaviour was deterministic: if a system received X, it would return Y. Even error states were expected; a 404 here, a 500 there, all of which could be handled with clear logic.

AI agents now consume APIs autonomously. They do not read documentation or follow expected paths. If a request fails, they may retry with variations. If an endpoint is undocumented, they may attempt to discover it. If no response is received, they may invent one.

An API that once assumed rate limited and well formed requests may now face creative, repeated or unexpected input. An agent asked to get the latest weather report might keep retrying variations if it fails, experimenting with parameters until something works. If the agent cannot access the API at all, it may simply hallucinate the result rather than give up. Worse, it may invent endpoints or arguments and persist in calling them. All of this can generate excess traffic, unnecessary cost and even instability, without any intent to cause harm.

Whilst it can be assumed that the vast majority were not created for malicious purposes, they cannot be assumed to be cautious. Agents can push at boundaries and assume that if something is available, it is acceptable to use. In doing so, they expose weaknesses that traditional client behaviour would never reveal; many so-called API security breaches have not involved hacking in any sophisticated sense. They were the result of simple misconfigurations, with endpoints left open, data exposed or permissions too broad, which an inquisitive agent may discover without any intent to cause harm.

APIs which are misconfigured and offer more information than they should are ripe for both intentional and unintentional exploitation by AI agents.

Many existing API designs and protections were created for a world where every call could be traced back to a human decision. That assumption is disappearing. Systems now need to expect that an unknown agent, acting independently, might be exploring, retrying or chaining multiple APIs together to complete a goal.

The rise of agentic workloads forces a new level of responsibility. If APIs are the interfaces through which intelligent systems act, then those interfaces must be designed with far more resilience, clarity and control than ever before.

Why API Security and Governance Matters

As we’ve already explored, APIs have become critical to the way the information services and applications work across the internet. This, however, brings a high level of risk and possible exposure. When an API is open, it is not just welcoming legitimate clients, it may also be available to unintended or unforeseen consumers. Security and governance exist best practices have therefore been developed to to prevent real harm.

Real incidents show what can go wrong:

These incidents happened before AI systems began calling APIs autonomously. Now imagine APIs being accessed not by a few developers but by thousands of agents, retrying, reformatting and escalating requests in pursuit of a goal.

The Need for Responsible Design

Good API governance is not about restriction, it is about clarity and control. Well-governed APIs:

  • Require authentication and define who may do what
  • Implement rate limits to stop runaway usage
  • Version their interfaces to avoid breaking changes
  • Provide documentation so behaviour is understood

APIs must now assume unpredictable clients. They must be explicit about boundaries. If something should not be possible, it must be prevented, not merely undocumented.

API Standards and Ecosystem

As APIs have grown in number, the industry has developed standards to keep them consistent and interoperable. Just as human communication relies on shared languages, APIs benefit from agreed technical conventions.

The most common style today is the RESTful API, which uses standard HTTP methods (GET, POST, PUT, DELETE) to operate on resources via URLs. REST is popular because it is simple, stateless and scalable. Most public web APIs follow REST principles and exchange data using JSON.

More recently, GraphQL has emerged as an alternative to REST. It allows clients to request exactly the data they need in a single query, improving efficiency for applications where bandwidth or performance matters. Rather than multiple endpoints, a single GraphQL endpoint can serve varied queries. It offers flexibility but can add complexity on the server side.

Standards also exist for describing and documenting APIs. The most prominent is the OpenAPI Specification, which provides a machine-readable format (in JSON or YAML) for defining endpoints, methods, parameters and responses. This enables the generation of interactive documentation, client libraries and server stubs, improving consistency and adoption across tools and platforms.

Other standards and technologies include AsyncAPI for event-driven systems, and gRPC, a high-performance RPC framework using Protocol Buffers over HTTP/2, often used in microservices. Each addresses specific needs but shares the goal of making integration predictable and developer-friendly.

Organisations with multiple APIs often enforce governance and best practices, covering naming, versioning, security and error handling. Consistency across APIs helps developers work more efficiently, much like a design system in user interfaces. API gateways and management platforms support this by enforcing authentication, rate limiting and other policies.

A Deeper Look at the API Lifecycle

You’ve seen that APIs require “careful lifecycle management,” but what does that really mean? Treating an API as a product involves guiding it through several distinct stages, from its birth to its eventual retirement. Understanding this lifecycle gives a fuller picture of what it takes to run a successful API.

  1. Planning and Design: This is the foundation. Before any code is written, a clear plan is established. What business purpose will the API serve? Who is it for? In this stage, the API’s architecture is designed, focusing on consistency, ease of use, and security. A good design is like a clear contract, setting expectations for how the API will behave.

  2. Development and Testing: With a solid design in hand, developers build the API and, just as importantly, its documentation. Throughout this stage, the API is rigorously tested for functionality (does it work?), performance (is it fast enough?), and security (is it safe?).

  3. Deployment and Monitoring: Once tested, the API is released into the world. This is often done via an API Gateway, which acts as a traffic controller and security guard. After launch, the API is continuously monitored to ensure it is running smoothly, to watch for security threats, and to understand how it is being used.

  4. Promotion and Distribution: An API is only useful if people know it exists. APIs are often published in developer portals or catalogues, which provide documentation and allow developers to sign up and start using them. This helps drive adoption and build a community of users.

  5. Deprecation and Retirement: Nothing lasts forever. When an API becomes outdated or is replaced by a newer version, it must be retired gracefully. This process starts with deprecation, where the API is marked as no longer recommended but is kept running for a period. Finally, after giving users plenty of notice and a clear path to migrate to a replacement, the API is retired and taken offline for good.

Exploring API Monetisation Models

When we say that companies like Stripe and Twilio deliver value through APIs, we mean they have turned their technical interfaces into successful products. There are several common models for how companies generate revenue from their APIs

Pay-As-You-Go (Usage-Based): This is the most direct model. Users are charged based on how much they use the API,for example, per API call or per gigabyte of data transferred. This is the model used by Twilio for sending text messages and by Google Maps for displaying maps.

Subscription-Based: Users pay a recurring fee (e.g., monthly) for access to the API. This model often uses tiers, where higher-priced plans offer more features or higher usage limits. It provides a predictable revenue stream and is common for Software-as-a-Service (SaaS) platforms.

Freemium: This model offers a free, basic tier of access to encourage developers to start using the API without any commitment. As their needs grow, they can upgrade to paid tiers for more advanced features or higher limits. Spotify and Dropbox both use this model to great effect.

Transaction Fee: For APIs that process payments or other transactions, it is common to charge a small fee or a percentage of each transaction. This is the core business model for payment gateways like Stripe and PayPal.

Indirect Monetisation: Sometimes, an API is offered for free because it drives revenue for another part of the business. For example, Shopify offers powerful APIs that allow developers to build apps for its e-commerce platform. These apps make Shopify more valuable to merchants, which in turn drives Shopify’s main revenue from store subscriptions.

The OWASP Top 10 API Security Risks

To add weight to the discussion on API security, it’s helpful to reference the OWASP API Security Top 10. OWASP (the Open Web Application Security Project) is a not-for-profit foundation that works to improve software security, and its Top 10 list is the industry-standard guide to the most critical API security risks. The real-world incidents you’ve already read about map directly to these official risk categories.

Here are some of the most common risks:

API1:2023 - Broken Object Level Authorisation (BOLA): This is the primary risk. It happens when an API doesn’t properly check if the user making a request has the right to access the specific data object they are asking for. The Connected Cars example, where anyone could control a car using just its VIN, is a perfect illustration of BOLA.

API2:2023 - Broken Authentication: This occurs when authentication is implemented incorrectly, allowing attackers to bypass it or steal tokens to impersonate legitimate users. The Experian incident, where an API could be tricked into giving up credit scores with easily found public information, is a classic example.

API3:2023 - Broken Object Property Level Authorisation: This is a more granular version of BOLA. It occurs when an API exposes sensitive data fields that a user shouldn’t be allowed to see or modify. The Geico breach, where the API leaked driver’s license numbers through its autofill feature, falls into this category.

API4:2023 - Unrestricted Resource Consumption: If an API doesn’t have limits on how many requests can be made (rate limiting), it can be overwhelmed by too many calls. This can lead to a Denial-of-Service (DoS) attack or result in huge costs being incurred. This is a major concern in the age of AI agents, which can make requests relentlessly.

API5:2023 - Broken Function Level Authorisation: This flaw allows a regular user to access functions that should be reserved for administrators or other privileged users. An attacker might be able to exploit this to change other users’ data, delete records, or access sensitive administrative controls.

Conclusion

From the simple weather update on your phone to the complex financial transactions that power our economy, APIs are the invisible yet indispensable threads weaving our digital world together. They have evolved from simple technical interfaces into strategic business assets and the essential building blocks for innovation. As we enter an era where AI agents interact with these interfaces autonomously, our responsibility as creators and consumers of technology intensifies. Building a future that is both interconnected and secure demands that we design APIs with intention, govern them with clarity, and protect them with vigilance. The next generation of digital services will not be defined just by what they can do, but by how responsibly they are built.