A 30-staff insurance brokerage was choosing between two CRM platforms last quarter. Both salespeople volunteered “we have an API” inside the first thirty seconds of the demo. The brokerage’s IT advisor probed. Vendor A’s API was read-only, capped at 1,000 calls a minute, supported basic webhook events, and used OAuth. Vendor B’s API could read and write contacts, run workflows programmatically, handle bulk operations, and offered a 100,000-call-a-minute ceiling with API-key authentication and a documented webhook signing scheme.
Both vendors said they had an API. One had built it as a tickbox in a feature comparison sheet. The other had built it as a product. The brokerage chose vendor B not for the CRM itself, but for what the API made possible, which was the actual decision the procurement question had been trying to surface all along.
Many owners hear “we have an API” and assume something has been promised. The interesting work is what comes after that claim.
What is an API?
An API, short for Application Programming Interface, is a published contract one piece of software offers another. The vendor exposes endpoints (specific URLs), your software sends an HTTP request, and the vendor returns a structured response, almost always JSON. The documentation is the binding spec. Reading it is how you find out what the integration can actually do, not what the salesperson said it could.
The contract framing is the useful one for an SME owner. Stripe’s payments API, HubSpot’s CRM API, OpenAI’s Chat API and Microsoft Graph across the M365 stack all share the same shape. Send this request, get that response, with rate limits and authentication and error codes documented in advance. Public APIs commonly follow the REST convention, using HTTP verbs like GET and POST against resource URLs. Some larger vendors offer GraphQL, which lets you ask for exactly the fields you want in one call. For procurement purposes the difference rarely changes the decision. The right opening question is still “do you have a REST API and where is the documentation.”
Why does it matter for your business?
It matters because the API decides whether you can integrate the tool with the rest of your stack, or whether you are buying another silo. A growing services SME runs five to fifteen platforms. Without good APIs the data sits in islands and someone re-keys it weekly. With good APIs the systems talk in real time and the re-keying disappears.
The asymmetry is brutal. A vendor with a well-designed API and a plain-language documentation page lets you wire up a payment-to-accounting flow in an afternoon using Power Automate or Zapier. A vendor with a thin or undocumented API costs you weeks of bespoke development, or forces you to keep doing the manual reconciliation that the new tool was supposed to remove. Same monthly licence, very different total cost of ownership. The API quality is usually the bigger driver of that gap than the headline product features.
Where will you actually meet it?
You meet APIs in three places. The first is the vendor pitch, where the phrase “we have a comprehensive REST API” gets dropped into the demo. The second is the documentation page, which serious vendors publish openly and is the most honest signal of how the API is treated. The third is the no-code tools (Power Automate, Zapier, Make) that wrap APIs in pre-built connectors.
Three concrete patterns are doing a lot of the SME work in 2026. A Power Automate flow that watches a SharePoint folder, calls the Stripe API to look up the invoice, and emails the customer when the payment lands. A daily script that calls the Companies House API to refresh client records in the CRM. An AI-assisted support inbox that sends each ticket through the OpenAI or Anthropic Chat API with a knowledge-base snippet and drafts a reply for the agent to refine. None of these need a software product built. All three need the underlying APIs to be well designed, documented, and priced sensibly. (See also our explainers on API keys, OAuth, webhooks, and MCP, the four sibling concepts that show up around APIs in vendor pitches.)
When to ask vs when to ignore
Ask the four procurement questions any time the integration actually matters. What does your API let me do, read-only or read-write? What is the rate-limit ceiling and how do I raise it? What is the authentication model, OAuth or API keys? Where is the documentation, and is there a sandbox to test before signing? Vendors who answer cleanly have built the API as a product. Vendors who deflect, or who route you to a sales engineer for basic facts, are signalling that the API is closer to marketing than to engineering.
Ignore the API question entirely when there is genuinely no integration need. A standalone tool used by one person, a one-off internal utility, a system that will never need to share data with anything else, none of those benefit from an API conversation. The mistake is the opposite: assuming “we have an API” closes the integration question when in fact it has barely opened it. Treat the claim as a starting position. Read the documentation page, try the sandbox if there is one, and price the integration risk before signing.
Related concepts
Five terms cluster around APIs and vendor pitches use them interchangeably: API key, OAuth, webhook, SDK, and MCP. They are not synonyms, and knowing which is which lets you ask the right follow-up question rather than nodding through the demo. Each one names a different layer of the contract you are signing up to when you integrate with a vendor.
An API key is the long alphanumeric string that authenticates your software to the vendor’s API. Treat it like a password and never paste it into source code. OAuth is the more sophisticated authentication flow used when the API is acting on behalf of a specific user rather than your whole account. A webhook is the inverse of a normal API call: instead of you asking the vendor for updates, the vendor pushes events to a URL you provide, which is how Stripe tells you a payment cleared.
An SDK is a pre-written wrapper library that makes calling an API easier in a specific programming language. MCP, the Model Context Protocol, is the 2026 standard for letting AI agents discover and call tools, sitting one layer above traditional APIs. The underlying point is the same one that started this post. A published interface only becomes useful when you have read the contract behind it.
If you want a second pair of eyes on a vendor’s API documentation before you sign, book a conversation.
