API

An API lets one system request data or an action from another. The same project system may expose one API operation for reading a record and another for creating an invoice, so they need different permissions and checks. The OpenAPI Specification 3.2.0, published September 19, 2025, describes HTTP APIs through paths, operations, inputs, responses, and security schemes. RFC 9110, published in June 2022, explains when repeating a request should have the same intended effect. Those standards describe the connection. A service firm still needs a narrow identity, proof that the right business record changed, a safe way to handle a missing response, and a named person who owns failure. An API starts the connection. The maintained integration makes it usable in client delivery.

What does an API do?

An API exposes selected data or actions from one system to another. The caller sends a request in an agreed format. The service checks the request, performs an allowed operation, and sends back a response.

Suppose a project system offers get_project_status. The request contains a project ID. The response contains the stage, due date, and source record ID. The same system may offer create_task, which accepts a project ID, owner, due date, and task text. One operation reads. The other changes a record.

The path, operation, required fields, response shape, errors, and security rules form the API contract. OpenAPI gives people and software a standard way to describe and inspect that contract without opening the service’s source code.

The contract does not describe the whole business job. A create_task response may say that the task was accepted. It does not prove that the task belongs to the right client, has the right owner, or will be seen before its due date. The delivery process has to supply those checks.

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.

Term	What it defines	Service-firm example
API	How software requests data or an action from a service	Read a project record from the project system
Integration	The full connection, including mapping, credentials, retries, logs, and ownership	Keep approved project status in sync with the CRM
Webhook	A notification one system sends when an event happens	Tell the billing system that a proposal was signed
AI tool	One bounded capability a model may request	Look up the current scope before drafting an update
MCP	A shared protocol for exposing selected data and tools to compatible AI applications	Make the project lookup available to several assistants
Computer use	Screen-based access through clicks and typing	Read a legacy portal that has no usable 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 are available. The model can request one with structured arguments. The application checks the request, applies its identity and permission rules, calls the underlying 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 its arguments. The application runs it.

That boundary matters in a service firm. An API may expose fifty operations. A proposal assistant may need only read_approved_rate_card and save_internal_draft. The tool layer exposes those two capabilities and leaves the others out.

Model Context Protocol can expose selected tools through a common AI-facing interface. The underlying service may still use its own API. MCP standardizes how compatible hosts discover the capability. The API defines how software reaches the service behind it.

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?

A safe connection gives each business operation its own authority and evidence. The account that reads a project record should not also be able to send a client email.

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 a workflow that creates an invoice. The billing service saves it, but the connection drops before the response reaches your system. The workflow cannot tell whether the write happened. A blind retry may create a second invoice. Stopping may leave the first invoice outside the project record.

RFC 9110 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. A POST that creates a new record is not automatically idempotent.

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.

Safe retry is only one layer. The workflow still needs a stable business identifier, a record of each attempt, and a check that compares records across systems. “200 OK” means the API answered. Completion means the correct invoice exists once, belongs to the correct client, matches the approved amount, and appears where finance expects it.

What should a service firm test before using an API in production?

Test the connection against the mistakes your weekly work can produce. A call that works once is a demo, not a production check.

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. Send the same request twice. Drop the response after the write. Reject a required field. Return a success response with the wrong business identifier. Confirm that the workflow can detect an uncertain outcome without guessing.

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. The system checks the response, saves evidence, and routes failure to a named person. Ongoing system access then becomes part of an AI employee.

At Stage 3, AI-native, the firm maintains APIs and the rules around them as part of delivery. Changes are tested. Permissions are reviewed. Failures have owners. Adding more endpoints does not create Stage 3 by itself.

When should a service firm 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.