What Is an API? A Plain Definition for Sales and Ops Teams

An API is the part of an app built for other software to use, the way buttons and menus are the part built for people. When a signup form creates a contact in your CRM, or a deal marked won appears in your billing tool a few seconds later, one system sent a request to the other's API and got an answer back.

You rarely see an API, but you feel its limits: a sync that stopped overnight, a field that never maps across, an integration that's only on the pricier plan. Knowing what happens underneath makes those problems easier to diagnose.

Where the definition comes from

The standard definitions agree on the core idea: an API is a contract between programs. MDN Web Docs describes it as the features and rules inside an application that let other software interact with it, as opposed to a human user interface. Clay's glossary puts it as a set of definitions and protocols that let applications talk to each other.

The word covers more than the web. An operating system, a code library and a database all have APIs. In sales and marketing conversations, though, "the API" almost always means a web API: an address on the internet that accepts requests over HTTP, the same protocol your browser uses. Many of these follow REST, a style Roy Fielding described in his 2000 dissertation, where each request carries everything the server needs to understand it.

What one API request contains

A web API request has four parts, and the answer comes back as a fifth: the response. Seeing them laid out explains most of the error messages people forward to IT.

• The endpoint: the address of the thing you want, such as the contacts in a CRM.
• The method: what you want done with it. MDN's reference lists the common ones: GET reads, POST submits something new, PUT replaces, PATCH changes part of a record, DELETE removes it.
• Credentials: a key or token that tells the other system which app or account is asking.
• The body: the data you're sending, usually as JSON, a plain text format of named fields.
• The response: a status code saying how it went, plus any data that came back, such as the new record's ID.

An example: a new lead lands in HubSpot

Say someone fills in the demo form on your website and the form tool is connected to HubSpot. Behind the scenes, the form tool sends roughly this to the endpoint described in HubSpot's contacts guide:

POST /crm/v3/objects/contacts
Authorization: Bearer <your app's token>
Content-Type: application/json

{
  "properties": {
    "email": "new.lead@example.com",
    "company": "Example Co"
  }
}

HubSpot's guide requires at least an email, first name or last name on a new contact, and recommends always sending the email, since it's the main way HubSpot avoids duplicates. If the request works, the form tool gets back a success code and the new contact's record ID. A later step, like adding the contact to a sequence, uses that ID in a request of its own.

What the error codes mean

Status codes are three-digit numbers sent back with every response: codes in the 200s mean it worked, the 400s mean something was wrong with the request, and the 500s mean the other system failed. The ones that turn up in integration logs, with meanings from MDN's status code reference:

A 401 means the connection itself is broken. A 403 means it works but the account behind it lacks a permission, worth checking first if the person whose account runs the connection has changed role.

Keys, tokens and rate limits

Credentials decide who may call an API, and rate limits decide how often. An API key is a long string that identifies the calling app or project. Google Cloud's documentation notes that a standard key ties requests to a project for billing and quotas but doesn't identify a user, and warns that unrestricted keys are insecure. Treat a key like a password: don't paste it into shared docs or chat, and revoke it if it leaks. Many sales tools use OAuth instead, the "Sign in with…" screen that grants an app access to your account without handing over your password.

Rate limits cap how many calls an app can make in a period. HubSpot publishes its own in its usage guidelines:

Past either limit, HubSpot answers every further call with a 429 error, and the daily count resets at midnight in the account's time zone. The daily limit is shared by every app connected to the account, so a heavy enrichment tool can starve your form sync. Bulk imports and large backfills are worth scheduling with that in mind.

API vs. integration vs. webhook

An API is the door; an integration is something built to walk through it. A native HubSpot and Gmail integration, like the one in our HubSpot and Gmail guide, is software someone wrote that calls both products' APIs so you don't have to.

A webhook reverses the direction. With an API, your system asks for data when it wants it; with a webhook, the other system sends a message to an address you give it when something happens. GitHub's documentation puts the trade-off simply: webhooks deliver data as it happens and cost less than polling an API over and over, which eats into rate limits, while a direct API call suits occasional lookups.

MCP, the Model Context Protocol, is a newer layer on top. Its official introduction describes it as an open standard for connecting AI applications to outside systems, so an assistant can find a product's tools and use them without a custom integration for each one.

Merlin, the Mac assistant we make, uses webhooks in both directions for its routines, tasks you set up to run on their own. An inbound webhook gives a routine its own URL, so any system that can send JSON, such as a form tool or a billing tool, can start it. An outbound webhook posts the routine's result to your server when a run completes or fails. Separately, apps connected over MCP in Settings → Integrations let Merlin read from and act in tools like Slack, Notion and Linear.

Questions to ask before you rely on a tool's API

Whether a sales tool has an API matters less than what that API lets you do on your plan. Before you buy, or before you build a process around a sync, ask:

1. Is the API included on our plan? Check the plan you'd actually buy, not the product in general, along with its limits.
2. Can it write, or only read? Pulling a report is different from creating contacts or updating deal stages.
3. Which objects does it cover? Contacts and companies are usually there; custom fields, activities and notes vary.
4. What are the rate limits, and are they shared? A shared daily limit means one busy tool can stop the others.
5. Does it send webhooks? Without them, every "real-time" sync is really checking on a timer.

Enrichment tools that fill in a lead's industry the moment a record is created call a data provider's API, the real-time form of data appending, which means adding missing details to records you already hold.

Common mistakes with APIs

• Treating "has an API" as "integrates with us". An API is raw material; someone still has to build and maintain the connection.
• Ignoring failed calls. Errors often sit in a log nobody opens. A sync that has returned 401 for a week looks exactly like one with nothing new to send.
• Tying the connection to one person. When that person leaves and their account is switched off, every sync running under it stops.