API (Application Programming Interface)

What is an API?

API stands for Application Programming Interface. It is a contract that lets one piece of software use another piece of software without knowing how it works inside. The contract says what you can ask for, how the request should look, and what kind of response you should expect.

In a data project, APIs are everywhere. Your accounting system exposes invoices through an API. Your CRM exposes companies, contacts, deals, and activities. Your webshop exposes orders and product stock. A connector is the software that reads those APIs and brings the data into a warehouse, lakehouse, automation flow, or application.

A useful mental model is the front desk of a hotel. You do not walk into the back office to search the reservation system yourself. You ask at the desk in the accepted way, the staff checks what you are allowed to see, and you get an answer in a predictable format.

How a web API works

Most APIs used in business integrations are web APIs. They use HTTP, the same protocol your browser uses. A client sends a request to a URL. The server checks authentication, runs the operation, and sends a response.

A request usually contains a few parts:

• Endpoint: the URL for the resource, such as invoices or customers.

• Method: the action, often GET, POST, PUT, PATCH, or DELETE.

• Parameters: filters such as date range, page number, or status.

• Headers: extra information, often including authentication and content type.

• Body: the data being sent, for example when creating or updating a record.

The response usually includes a status code and a body. A 200-range status means the request succeeded. A 400-range status means the client request was wrong or not allowed. A 500-range status means the server had a problem. The body is often JSON because it is readable, compact enough, and easy for software to parse.

REST, webhooks, GraphQL, and OpenAPI

REST
REST is the most common style for business web APIs. Resources have URLs, and standard HTTP methods describe what you want to do: GET to read, POST to create, PATCH or PUT to update, DELETE to remove.

Webhooks
A normal API call is pull-based: your system asks for data. A webhook is push-based: another system calls your URL when something happens. Webhooks are often paired with APIs. The webhook says an order changed; the API lets you fetch the latest order details.

GraphQL
GraphQL is a query language for APIs where the client asks for the exact fields it needs. That can be useful when a screen or integration needs a specific shape of data and a fixed REST response would return too much or too little.

OpenAPI
OpenAPI is a standard way to describe HTTP APIs in a machine-readable document. Good OpenAPI documentation lets humans understand endpoints and lets tools generate clients, tests, and interactive API references.

Why APIs matter for data integration

Every modern connector is built around an API contract. If a SaaS tool has a stable, documented API, data can usually be extracted automatically and repeatedly. If it does not, the alternatives are weaker: manual exports, email attachments, scraping screens, or direct database access.

For reporting, this matters before you buy software. A package may look fine in the user interface but become a data island if its API is missing, locked behind a higher plan, too limited, or poorly documented. The API determines whether you can bring its data into the rest of your stack without manual work.

APIs also shape how a sync is designed. Large responses are often paginated, so a connector must request page after page. Many APIs have rate limits, so the connector must slow down instead of hammering the service. Good APIs expose updated-since filters, which allow incremental loads instead of downloading the whole history every night.

API versus export versus direct database access

API versus file export
A file export is a snapshot. It is useful for one-off analysis, but it goes stale and usually depends on someone remembering to download it. An API can be called on a schedule, with credentials, logging, and repeatable structure.

API versus direct database access
Direct database access can look attractive because all the data is there. It is also fragile. Internal tables are not a public contract, and a vendor update can change them without warning. APIs are slower and more limited by design, but that design is what makes them safer for integrations.

API versus webhook
They are not opposites. Webhooks tell you that something happened. APIs let you ask for details, backfill missed data, and reconcile state.

What to check in API documentation

• Authentication: API key, OAuth, service account, scopes, and token expiry.

• Endpoints: which objects are available and which fields each object returns.

• Pagination: how large datasets are split across requests.

• Rate limits: how many requests are allowed per second, minute, hour, or day.

• Filtering: whether you can request only records changed since the last sync.

• Errors: how failures are reported and whether retries are safe.

• Versioning: how breaking changes are announced and how long old versions remain available.

What to watch out for with APIs

Credentials are production access
An API key or OAuth token can expose company data. Store it in a secrets manager or password vault, not in a spreadsheet, email, or script.

Rate limits affect architecture
A first historical load can take hours if the API only allows a small number of requests per minute. Design backfills and daily syncs separately.

Version changes break integrations
Subscribe to vendor changelogs for important APIs. A quiet deprecation notice can become a broken dashboard six months later.

Not every API is complete
Some APIs expose only part of the product. Always check whether the fields needed for reporting are actually available before promising the integration.