✦ Integration
API integration explained for non-technical decision makers
API integration is how two pieces of software exchange data without a person copying it between them. You don't need to write code to buy it well - you need to know what to ask a vendor before you sign the contract.
Haystak · 11 August 2026 · Updated 11 August 2026 · 7 min read
An API - application programming interface - is simply a documented way for one piece of software to ask another for information or to make something happen, without a human involved. When your accounting package retrieves the day's card payments from your payment provider automatically, that's API integration doing the work.
You don't need to understand how it's built. You do need to know, before you buy any new system, whether it has one, whether it's any good, and what it will and won't let you do - because that decision is much harder to reverse once you're relying on the software.
What an API actually is, without the jargon
Think of an API as a restaurant menu. You don't need to know how the kitchen works; you need to know what you can order, what it costs, and how long it takes. A software vendor's API documentation is that menu - a list of what data you can ask for or send, and the rules for doing it.
"API integration" is the work of building the two ends of that conversation: getting your system to ask the right questions, and making sense of the answers it gets back.
REST APIs and webhooks: the two patterns you'll meet
Almost every modern business system uses one of two patterns, often both. Knowing the difference helps you understand what a vendor means when they say "yes, we have an API".
| Pattern | How it works | Good for |
|---|---|---|
| REST API | Your system asks a question and gets an answer back immediately, on demand | Looking up a customer, creating an order, pulling a report |
| Webhook | The vendor's system tells yours the moment something happens, without being asked | Instant notification of a payment, a status change, a new lead |
A system with only a REST API means you have to keep asking "has anything changed?" on a schedule. A system that also offers webhooks can tell you the instant something does, which matters a lot for time-sensitive processes - see our note on sync vs event-driven integration for when that difference is worth paying for.
Authentication: how systems prove who they are
An API can't be open to anyone who finds the address, so every serious one requires authentication - proof that the request is coming from someone entitled to make it. The most common approach today is OAuth 2.0, a widely adopted standard (documented as an open specification by the IETF) that issues a token rather than sharing a password directly.
- API keys - a long, unique string that identifies your account. Simple, but treat it like a password.
- OAuth tokens - a more secure handshake, especially where a user needs to grant one system permission to act on their behalf in another.
- IP allow-listing - some systems also restrict which servers are allowed to connect at all, as a second layer.
Rate limits and versioning: the small print that bites later
Two details in API documentation rarely get attention during a sales demo but matter a great deal once you're live. A rate limit caps how many requests you're allowed to make in a given period - useful to know if you're planning to sync large volumes of data overnight. Versioning tells you how the vendor handles changes to their own API over time.
- 01Check the rate limit against your volume. A limit of a few hundred requests a minute is plenty for most businesses; it isn't if you're syncing tens of thousands of records nightly.
- 02Ask how long old API versions stay supported. Some vendors give a year's notice before retiring a version; others give a few weeks, which can break an integration with little warning.
- 03Look for a changelog. A vendor that publishes one is telling you they treat their API as a real product, not an afterthought.
What good API documentation looks like
You can judge a vendor's API without reading a line of code. Good documentation is published openly, often following the OpenAPI standard, includes working examples, and lists errors as clearly as successes. If a vendor can only describe their API verbally on a sales call, that's usually because it exists but has had little real investment.
| Sign | What it tells you |
|---|---|
| Public documentation, no login required | The vendor expects and supports integration as normal practice |
| A sandbox or test environment | You can prove the connection works before committing data to it |
| Listed rate limits and error codes | Someone has thought about what happens when things go wrong |
| No documentation, "ask our support team" | Integration is possible but likely to be slow and inconsistently supported |
When to build custom API integration vs use a connector
If both systems are mainstream and a pre-built connector already exists - through Zapier, Make, or a vendor's own app marketplace - that is very often the right, cheapest answer, and we'll say so plainly rather than propose custom work you don't need. Custom API integration is worth it when the connector doesn't cover the specific fields or logic you need, when volumes are too high for a no-code tool, or when one of the systems is bespoke and has no existing connector at all.
A short technical review of both systems' APIs, done before any commitment, will tell you which situation you're in. If you'd like ours, see our system integration service or get in touch directly.
✦ Where this fits
More on this from us: our system integration services.