API Access

Most online services are known to us through a website or an app. You type something in, click a button, and get a result displayed. Alongside this, there is a second way: a defined connection point through which another program addresses the service directly. This connection point is called an API, and the permission to use it is called API access. So instead of a human, it’s a foreign piece of software sitting at the controls. It sends a precisely formatted request to the provider and receives a precisely formatted response back, which it can then process further.

Why companies only get AI through the interface

Large language models run on expensive specialized hardware in data centers. Hardly any company could operate such a model itself. API access is the solution: the model stays with the provider, and the company only sends its requests there. Payment is based on consumption, usually per amount of text processed. Those who use little pay little, and no one has to buy servers in advance.

For providers, this is conversely an important business model. OpenAI, Anthropic, or Google earn a considerable portion of their money not from chat subscriptions for private individuals, but from companies that build their models into their own products via the interface. That’s why price cuts per request are regularly newsworthy. They help determine which AI applications are even worthwhile in the first place.

However, API access also creates a dependency. If the provider changes prices, rules, or the model itself, all customers must adapt. If an older model is shut down, an application built on it can suddenly behave differently. This is precisely why some companies test, in parallel, models that they can run on their own servers.

Request, key, and response

Technically, an API request is a message sent over the internet, similar to calling up a website. It goes to a fixed address of the provider and contains the data in a structured format. For a language model, this includes, for example, the text of the question and the name of the desired model. The response comes back just as structured, so that the requesting program can automatically read it out.

So that the provider knows who is making the request, every access comes with an API key. This is a long, random string of characters that functions like a password. It is sent along with every request and is used for billing. Anyone who knows this key can work at someone else’s expense. That’s why it should never be placed in publicly visible program code.

In addition, there are almost always limits. They restrict how many requests are allowed per minute, thereby preventing server overload. Anyone who exceeds this receives an error message instead of a response. Well-built programs then wait briefly and try again, rather than simply crashing.

Where third-party interfaces work behind the scenes

Many programs used daily are, to a large extent, assembled from third-party APIs. A delivery service app fetches the map from a mapping service, the payment from a payment provider, and the address verification from a third service. The provider of the app mainly writes the part that brings everything together. None of this is visible to the user.

It’s the same with AI. When an online shop suddenly generates product descriptions automatically or a support chat gives sensible answers, there is usually no proprietary model behind it. It is API access to a large provider, embedded into one’s own interface. Many programming tools and writing assistants work this way too.

In business news, the term therefore often appears in connection with revenue and power questions. A common misconception is that API access means access to the model itself. That is not true: you may use it, but neither download it nor look inside it. Anyone who wants that needs an open model, whose blueprint and weights are freely available.