On this page
Read
The useful mental model
An API is a guarded boundary with a contract. A client sends an authenticated, structured request to an endpoint. The service validates and processes it, then returns a structured response or error. The client remains responsible for deciding what that result means and what happens next.
In plain English
It is a service counter for software. Your app submits a request in the expected format, and the service returns a result or explains why it could not.
Where builders use it
- 01Integrating AI models into products
- 02Exchanging structured data between services
- 03Orchestrating backend workflows
Why it matters
An API creates a stable boundary between systems. Builders can validate inputs, authenticate callers, interpret status and error data, and change either side without exposing the service's internal implementation.
Why now
Most production AI features reach models, tools, and data services through APIs. Reliable integrations must handle authentication, schemas, rate limits, transient failures, and request identifiers in addition to the successful response.
A common misconception
“An API is an autonomous agent that decides what to do next.”
An API exposes operations through a contract. The calling application or workflow chooses when to call it, validates the result, handles errors, and decides the next action.
See
See the mental model
The visual is generated from the same structured knowledge as the written explanation.
A client sends a structured API request across a validated boundary. The service returns a response or error, and the client application decides how to handle that outcome.
Watch
Watch the explainer
A short visual explanation built from the same reviewed knowledge object.
API: a contract between software systems
Follow a model API request across an authenticated boundary, through validation and processing, and back to client logic that must interpret success, errors, and retryable failures.
Read transcript
An app asks an AI model a question through an API. An API is a documented way for one program to ask another for something. The request carries an address, a login, and the question in the right format. Before any model runs, the service checks it. Is the caller allowed? Is the format right? Is it within limits? If all is well, the reply holds a success status and the answer. If not, the reply says what went wrong, such as invalid input or a timeout. The app reads that outcome, then shows the answer, rejects bad input, or retries a temporary failure. An API does not decide the workflow. It is a contract that includes a clear way to report failure.
Builder example
Handle a model request beyond the happy path
A workshop assistant sends a learner's question to a model API and expects a structured answer that the product can display.
Failure
The integration assumes every call succeeds, ignores status and error data, and treats a timeout or rate-limit response as if it contained a valid answer.
Intervention
Authenticate the request, validate its input, check the HTTP status and response schema, log the request identifier, and retry only eligible transient failures with bounded backoff.
Observable result
Successful responses reach the learner in the expected shape, invalid requests fail visibly, and temporary service failures enter a limited recovery path instead of becoming fake answers or endless retries.
Sources
Go deeper
Last researched 11 October 2026