Skip to content

Glossary

APIapplication programming interface

An API is the published route by which one piece of software talks to another, so a program can ask another program for something and get a usable answer back with no person in between.

In plain terms

It is a service counter with a published list of what you may ask for and what form the answer arrives in. Nobody gets to walk into the back office and rummage. You ask at the counter, in the agreed way, and you receive the agreed thing. The published list is the entire point, because it lets somebody build against the counter without negotiating each time they turn up.

01

Why it matters

When somebody asks whether a product has one, the real question is whether you can get your own material out and whether anything can be built on top, which makes it a question about how stuck you would be. In AI specifically it is also where the economics change: the same model reached this way is generally charged by the amount of text rather than by the person per month, and it exposes settings the friendly interface hides. That single difference decides whether a high-volume idea is affordable.

02

How it works

It defines requests and responses, and that definition is the thing being published. Which operations exist, what you must supply for each, what comes back and in what shape. Because it is written down and stable, somebody can build against it and expect their work to keep functioning, which is a promise rather than a technical property.

You identify yourself with a key, and that key carries both your permissions and your bill. This is worth dwelling on because a key is not much like a password: anyone holding it is you, there is usually no second step, and it is frequently pasted into a script that ends up somewhere public. Leaked keys are among the most common and most expensive mistakes in this whole subject.

Interfaces refuse you if you ask too quickly. Limits on how many requests you may make in a period are normal, published and deliberate, and hitting one is a thing to design around rather than a fault to report. Anything you plan to run at volume needs to know its limits before it meets them at three in the morning.

A published interface is a promise with a version attached, and providers do change and retire them. Notice periods vary, migrations are real work, and the older an integration is the more likely it is to be depending on something already deprecated. Anything you build on somebody's interface is a dependency that deserves the same attention as any other supplier.

For AI specifically, what you reach this way is often not the same product as the chat window. Different defaults, different settings exposed, different limits, and sometimes a different model underneath the same name. That is why a workflow built against the interface can behave unlike the assistant the same team tested in a browser.

The service counter, and the three answers it gives

The service counter, and the three answers it givesOne route, one contract, and refusals are part of it rather than a sign of trouble. Your software asks in the published way, identifying itself with a key, and an answer comes back along with a count of what it consumed, which is how the eventual bill is assembled. Ask faster than the agreement allows and the same route answers with a refusal instead, which well-built software expects and waits out. That is the whole shape. Everything that makes this a supplier relationship rather than a technical detail sits in those four messages: the key that is you, the count that becomes the invoice, and the refusal that has to be designed for rather than escalated.a request,carrying your keyhere it is, andhere is what itconsumedthe same request,too quicklyslow down, youare over thelimitYour softwareTheprovider'sservice
One route, one contract, and refusals are part of it rather than a sign of trouble. Your software asks in the published way, identifying itself with a key, and an answer comes back along with a count of what it consumed, which is how the eventual bill is assembled. Ask faster than the agreement allows and the same route answers with a refusal instead, which well-built software expects and waits out. That is the whole shape. Everything that makes this a supplier relationship rather than a technical detail sits in those four messages: the key that is you, the count that becomes the invoice, and the refusal that has to be designed for rather than escalated.

One request, and the three replies you should expect

One request, and the three replies you should expectAn illustrative exchange, and everything a buyer needs is visible in it. The second line is a key, which is nothing like a password: it is a bearer, so anyone who has it is you, and it usually arrives with no second factor and no confirmation step. The fourth line is the published contract, the part a version number attaches to and the part a provider is promising not to change without notice. The answer comes back with a count of what it consumed, which is the mechanism the eventual bill is built from and the first place to look when the bill surprises you. And two of the three replies are refusals, which is the honest shape of the thing: being told to slow down is expected behaviour rather than a fault.POST /v1/generateAuthorization: <your secret key>1{ model, prompt, max_output }2-> 200 { text, usage: { input, output } }3-> 429 slow down, you are over the limit4-> 401 that key is not valid1Whoever holds this line isyou, with your permissionsand your spending. Usuallyno second factor, and noprompt asking whether youmeant it.2What you may ask and whatyou must supply. This listis the published promise,and it is what a versionnumber is attached to.3The answer arrives with acount of what it consumed,which is how the invoice isassembled and where anunexpected bill can betraced.4Being refused for asking toofast is normal anddeliberate. Design for itrather than escalating it.
An illustrative exchange, and everything a buyer needs is visible in it. The second line is a key, which is nothing like a password: it is a bearer, so anyone who has it is you, and it usually arrives with no second factor and no confirmation step. The fourth line is the published contract, the part a version number attaches to and the part a provider is promising not to change without notice. The answer comes back with a count of what it consumed, which is the mechanism the eventual bill is built from and the first place to look when the bill surprises you. And two of the three replies are refusals, which is the honest shape of the thing: being told to slow down is expected behaviour rather than a fault.
03

Seen in the wild

  • Send one request to models from several different providers through a single interface, which is the whole idea in its most compressed form.

    OpenRouter

  • Add a step to an automation that calls another system's interface directly, without anybody writing code, which is where most non-developers first meet one.

    n8n

  • Reach a system with no pre-built connection by using a generic request step, which is the underlying route in the open rather than packaged.

    Make
04

Common misconceptions

People assume

Having one means we can get our data out.

In fact

It means some things can be reached programmatically, and which things is a separate question with a specific answer. Plenty of interfaces let you create records and not export them in bulk. If portability is the reason you are asking, ask about export directly rather than accepting the existence of an interface as the answer.

People assume

It is the same product as the app.

In fact

Frequently it is not. Features present in one are absent from the other, defaults differ, limits differ, and the model behind a named product can differ from the one the interface gives you. Test the route you intend to use in production rather than the one that was convenient for the evaluation.

People assume

A key is like a password.

In fact

It is more dangerous than one. Whoever holds it is you, with your permissions and your spending, usually with no second factor and no prompt. Keys belong in a secrets store rather than in a spreadsheet, a shared document or the code itself, and they should be rotatable without anybody having to think hard.

05

Telling them apart

API vs Connector

API

The general published route. Works for anything the provider exposes, and expects somebody technical at your end.

Connector

A specific pair of products joined up in advance, with sign-in, field matching and error handling already done.

Nearly every connector is built on one of these. When no connector exists for the pair you need, the route underneath usually still does, which makes it a development job rather than a dead end.

API vs Webhook

API

You ask. Nothing happens until your software makes a request, so you decide when and how often.

Webhook

It tells you. The other system sends a message the moment something happens, so you find out immediately and have to be listening.

Checking every five minutes for something that happens twice a day is the case a webhook exists to fix. Needing an answer right now, on demand, is the case it cannot help with.

06

Questions

Do we need developers to use one?
Not always. Automation platforms include steps that call an interface with the details filled into a form, which covers a good deal of ordinary work. Developers become necessary when something has to handle failures properly, respect limits under load, or keep a key safe in a system many people can see.
Why is this cheaper than the app for the same model?
Different charging model rather than a different deal. The app is generally priced per person per month and includes the interface, the storage and the support around it. The route underneath is charged by the amount of text, which is far cheaper for occasional unattended use and can be far dearer for constant heavy use.
How do we keep a key safe?
Keep it out of code, documents and messages, store it somewhere built for secrets, give separate keys to separate uses so one can be revoked alone, and make rotating one a routine somebody has actually practised. Also set a spending limit if the provider offers one, because that turns a leak into a bill rather than a catastrophe.
What if the provider changes it?
Then work is required, on their schedule rather than yours. Providers usually give notice and run old and new versions side by side for a period. The thing worth knowing before you build is how much notice a provider commits to, since that number is the difference between a planned migration and a weekend.
07

Key takeaways

  • It is a published contract for how software asks software for things, and being published is the point.
  • A key carries your permissions and your bill, and has none of the protections a password has.
  • Rate limits are normal and deliberate, and anything running at volume should know its own before it meets them.
  • The interface and the app are often different products with different defaults and limits.
  • Building on somebody's interface is a supplier dependency, complete with deprecations and migrations.
08

Related terms

09

Tools that use this

  • OpenRouter

    One route reaching many providers, which is the idea compressed.

  • n8n

    Calling an interface from a form rather than from code.

  • Make

    A generic request step for systems with no packaged connection.

Last checked July 2026

All glossary terms