API

An API lets one software system ask another for data or an action. Your workflow might use it to read a project record or create an invoice, without somebody opening the software and clicking through the screens.

Those two actions need different permissions and checks, because reading a record and creating a bill have different consequences. The connection also needs a safe way to handle a missing response and someone who takes over when it fails.

That’s the work around the API that makes it useful in client delivery, making sure the right record changed and knowing what to do when you’re not sure it did.

What does an API do?

An API makes selected data or actions available to other software. The software asking sends a request in an agreed format, and the service checks it, performs the allowed action, and sends back a response.

Suppose a project system offers get_project_status, where you send a project ID and get back the stage, due date, and source record ID. It may also offer create_task, which takes a project ID, owner, due date, and task text.

The first operation reads information, while the second changes the system by creating a record.

The API contract tells you where to send the request, which action to ask for, which fields it needs, what comes back, and how errors and security work. The OpenAPI Specification 3.2.0, published September 19, 2025, gives people and software a standard way to describe those details for HTTP APIs without reading the service’s source code.

A create_task response may tell you the task was accepted, but it doesn’t prove it belongs to the right client, has the right owner, or will be seen before its due date. Your delivery process still has to check those things.

Is an API the same as an integration?

An API is an interface. An integration is the maintained connection that uses that interface to move real work between systems.

For example, the API lets you read a project record, while the integration keeps approved project status in sync with the CRM. That integration has to match the fields, manage access, handle retries, record what happened, and get failures to an owner.

A webhook starts from the other direction, one system sends another a notification that something happened, such as a proposal being signed. An AI tool is a limited action you let a model request, such as looking up the current scope before drafting an update.

MCP provides a shared way to offer selected data and tools to compatible AI applications, so several assistants can use the same project lookup. Computer use takes a different route, clicking and typing through a screen when, for example, an old portal has no useful API.

A vendor can say that its product has an API while leaving out the operation your process needs. It may let you list invoices but not create one. It may expose every project while offering no field-level permission.

Treat “has an API” as the first question, not the answer. Ask whether the exact read or write exists. Ask how it is authorized, how changes are announced, what the response proves, and what happens when either system is unavailable.

How does AI use an API?

AI usually reaches an API through an application and a limited tool. The model should not receive unrestricted access to every endpoint.

The application tells the model which tools it can request and what inputs each one needs. When the model asks for a tool, application code checks the request and permissions, calls the API, and sends the result back.

Google’s function-calling guide, updated July 7, 2026, puts execution in the application. The model chooses the function and supplies the inputs, but the application is what runs it.

An API may offer fifty operations while your proposal assistant needs only read_approved_rate_card and save_internal_draft. Give it those two tools and leave the others out.

Model Context Protocol gives compatible AI applications a common way to discover selected tools. The service behind a tool may still use its own API, so MCP and the API can be parts of the same connection.

An AI agent may choose among several tools while pursuing a goal. The API does not supply the goal or the choice. Computer-use AI takes a different path by operating the screen. A typed API is usually easier to limit, test, and monitor when the software offers one.

What makes an API connection safe enough for client work?

Decide permission for each business action separately. If the job is only to read project records, its account shouldn’t also be able to send client emails.

OWASP’s 2023 API Security Top 10 release says three of its first five risks concern authorization. The object, its fields, and the function each need checks. A token can identify the caller without proving that the caller may read this client’s record, change this field, or run an administrative action.

Write down six things before an API touches delivery:

1. Operation. Name the exact read or action. read_project_health is easier to review than access_project_system.
2. Identity. Give the connection its own account or delegated identity. Do not borrow the owner’s credentials because setup is faster.
3. Scope. Limit clients, records, fields, actions, and destinations to this job.
4. Approval. Put a person before money moves, a client message sends, access changes, or a record that is hard to restore disappears.
5. Proof. Save the request ID and check the system of record that must contain the finished work.
6. Recovery. Name what retries, what stops, and who receives an uncertain result.

The approval step should match the consequence. Use the check for whether a result can be checked and an action undone. A read-only lookup over approved records can usually run with less supervision than a client email or invoice.

Why can a successful API call still leave the job unfinished?

An API response tells you what one service did with one request. The business job may cross several services and may continue after that response.

Imagine the billing service saves an invoice, but the connection drops before the response reaches your workflow. Now the workflow can’t tell whether the invoice exists, and retrying blindly may create a second one, while stopping may leave the first one missing from the project record.

RFC 9110, published in June 2022, calls a method idempotent when repeating the same request has the same intended effect as sending it once. HTTP defines PUT, DELETE, and safe methods that way, but a POST that creates a new record doesn’t automatically have that protection.

Some services add their own protection. Stripe’s idempotent request design lets a caller attach a unique key to a create or update request. A retry with the same key returns the saved result instead of performing the operation again.

Even with safe retries, you need a stable ID for the business record, a record of each attempt, and a check across the systems involved. “200 OK” is a successful response to that API request, but you still need to confirm the invoice exists once, belongs to the correct client, matches the approved amount, and appears where finance expects it.

What should a business test before using an API in production?

Test the connection against the mistakes that can happen in your weekly work. Getting one call to work tells you the connection is possible, not how it handles those mistakes.

Start with one read-only operation. Run it against a valid record, a missing record, two clients with similar names, an expired credential, a denied field, a rate limit, a timeout, and a changed response field. Confirm that each case leaves a useful record and reaches the right owner.

Then add one reversible write and test duplicate requests, a response lost after the write, a rejected required field, and a success response with the wrong business ID. Check that the workflow notices when the result is uncertain rather than guessing what happened.

Version changes need an owner. A provider may remove a field, change an allowed value, or retire a version. Someone must watch its notices, run regression tests, and update the mapping before client work breaks.

Connection quality cannot repair the process behind it. Document the process first, because an API will carry unclear ownership and stale data into the next system with the same consistency as good data. The production gain comes when live systems and written rules work together.

Where does an API sit on the Delivery Model Ladder?

An API usually becomes operational at Stage 2, Augmented, of the Delivery Model Ladder.

At Stage 1, Enhanced, a person opens an assistant or automation, starts the work, reviews the result, and moves it to the next system. An API may make a lookup faster. The person still holds the workflow together.

At Stage 2, a trigger starts a defined workflow, the API reads or writes with limited permission, and the system checks the response, saves evidence, and sends failures to a named person. That ongoing access becomes part of the role of an AI employee.

At Stage 3, AI-native, maintaining APIs and their rules is part of delivery, with changes tested, permissions reviewed, and failures sent to their owners. Adding more API operations doesn’t create Stage 3 by itself.

When should a business skip the API integration?

Skip custom integration when the task is rare, cheap, low risk, and safe to complete with an ordinary export or manual action. A twelve-person firm does not need maintained code for a lookup someone performs twice a year.

Use a fixed import or export when work moves in a periodic batch and immediate synchronization has no business value. Use computer use when a repeated task matters but the old system offers no typed interface, while accepting that screen changes make the path more fragile.

For a first API connection, define one read-only business operation. Give it a narrow identity, an expected record, a failure owner, and a retry rule. Add one reversible write only after the read path survives missing, ambiguous, denied, delayed, and changed responses.