What is an API integration? A plain guide for businesses
An API integration connects two pieces of software so they can send and receive data without a person in between. An API (application programming interface) is the door a piece of software opens to the outside world, saying “ask me in this format and I will answer in that one”. The integration is the connection that uses that door — so that, for example, an online order lands in your accounts on its own.
Below we explain what an API is without assuming any technical knowledge, look at the integrations businesses ask for most, and cover how an integration is built and where it goes wrong if nobody is paying attention.
What is an API? An analogy
An API is the official channel one piece of software uses to talk to another. Think of a public office with a counter. You apply at the counter on a set form with set information, and the office answers in a set format. You do not need to know what happens behind the counter, and it is clear who may apply at which window.
An API works the same way:
- Request: “Give me today’s orders” or “Create a draft invoice for this customer.”
- Identity: a key or session proving the caller is authorised.
- Response: the list of orders, or “invoice created, here is its number”.
- Rules: which requests are accepted, how often you may ask, which fields are required.
All of these rules are written in the vendor’s API documentation. Good documentation is the first sign that an integration will go smoothly.
What is the difference between an API and a webhook?
With an API you ask; with a webhook the other system tells you when something happens. Using the API, you ask “any new orders?” at intervals. With a webhook in place, the shop sends a notice to an address you choose the moment an order arrives.
| API request | Webhook | |
|---|---|---|
| Who starts it? | Your system | The other system |
| When? | Whenever you ask | The moment the event happens |
| Typical use | Fetching lists, creating and updating records | New order, payment or form-submission notices |
| What to watch | Asking too often and hitting limits | Verifying the notice really came from that system |
Most integrations use both: the webhook says “something happened”, and the API is used to fetch the details and write them into the other system.
What is an API integration for?
An API integration removes the need to type the same information into more than one system. The most common scenarios:
- Orders and accounts. An order from the online shop opens as a draft in the accounting or invoicing system.
- Payments and records. A “payment received” notice from the payment provider updates the order status on its own.
- Shipping. A shipment is created and the tracking number reaches the order and the customer.
- Forms and CRM. A website enquiry opens a customer record in the CRM and assigns a task to the right person.
- Stock. Stock levels across several sales channels are updated from one source.
- Messaging. Conversations from channels such as WhatsApp are linked to the customer record; we cover that in WhatsApp Business API sales automation.
Which processes to automate first is the subject of automation for small businesses. This piece focuses on how those connections are built.
How is an API integration built?
An integration is built by reading both systems’ documentation, writing down how data maps from one side to the other, and designing for failure from the start. The steps are usually these:
- Describe the flow. On which event does which data go from which system to which? Does anything come back?
- Read the documentation. Do both APIs support this flow? Are the necessary fields available?
- Map the fields. One side may hold “Full name” in one field and the other in two. Tax numbers, addresses and product codes all need a mapping.
- Try it in a test environment. If the vendor offers a sandbox, the flow is tested without touching real data.
- Design for errors and retries. What happens if the other system does not answer? Will sending the same request twice create a duplicate?
- Log and monitor. Every transfer is logged; if something goes wrong, the right person hears about it.
- Go live and maintain. The first weeks are watched closely. Vendors change their APIs from time to time, so the connection needs maintenance to keep working.
Step five is the one most often skipped. Say a “create invoice” request is resent because a network drop swallowed the reply: a badly built integration raises two invoices for one order. The cure is to give every request a unique identifier, so that the other side refuses to create a second record when it sees the same one again.
Which route should you take?
There are three routes: your product’s ready-made connector, a no-code connection tool, or a custom integration. The right one depends on how complex the flow is, how much volume runs through it and how much visibility you want when something fails.
| Route | When it fits | Limit |
|---|---|---|
| Ready-made connector (plug-in, app marketplace) | Two common products and a standard flow | The flow is only what the product allows |
| No-code connection tools | Simple flows with few conditions, low volume | Per-task costs and limits bite as volume grows |
| Custom integration | Conditional steps, high volume, sensitive data, detailed error tracking | Needs a build and maintenance |
Our advice is to look at the ready-made connector first, and to consider a custom integration only where it falls short. Replacing a program only comes up if it allows no outside connection at all. The wider version of this decision is in off-the-shelf or custom software?.
What are the risks of an API integration?
The main risks are unauthorised access, flows that break silently and personal data moving about unchecked. On the security side, a good starting point is OWASP’s API Security Top 10. The 2023 edition puts broken object-level authorisation and broken authentication at the top. If you are opening an API of your own, use the list as a checklist.
On the business side, these are the points we recommend watching:
- Storing keys. An API key is a password. It is never written into code, an email or a shared document; it is kept somewhere secure and rotated regularly.
- Least privilege. An integration should read only what it needs to read and write only what it needs to write. A connection that reads orders is not given refund rights.
- Personal data. You should know which personal data goes to which system, in which country, and update your privacy notices to match — under GDPR in the UK and EU, or KVKK in Türkiye. Check the legal detail with your adviser.
- Silent failures. When a connection drops, the flow should stop and tell someone. A failure discovered weeks later through missing orders costs more than having no integration at all.
- Vendor changes. APIs are versioned and old versions are retired. Someone has to follow the vendor’s announcements.
- Limits. Most APIs cap the number of requests in a given period. Busy moments such as a sale day are planned around that.
Eight questions to ask a vendor
Before buying a piece of software or starting an integration, we suggest asking the vendor these questions. The answers largely decide whether the integration is possible and how much work it will take.
- Do you have public, up-to-date API documentation?
- Is there a test environment where we can try things without touching real data?
- Can you send webhooks for events? Which events?
- How does authentication work? Can we create keys with narrowed permissions?
- What are your request limits?
- How do you change API versions, and how long is an old version supported?
- Is API access charged separately, or tied to a particular plan?
- How do we reach your technical support when something goes wrong?
If the answer to the first two is no, the integration may still be possible but it will be laborious. Note it as a point against the product when you choose.
AI and APIs
AI tools also reach company systems through APIs. A language model reading a customer record or opening a ticket is, underneath, making an API call. We cover the emerging standard for describing those connections in what is MCP?, and adding a language model to business processes in ChatGPT integration for businesses. Every security rule above applies there just the same.
Frequently asked questions
Do we have to replace our software to integrate it?
Usually not. Most accounting, e-commerce, CRM and payment systems offer an API. We recommend trying to connect what you already use first; replacing a program only comes up if it allows no outside connection.
Will the integration break if an API changes?
It can. Vendors normally announce changes in advance and keep the old version running for a while. That is why integrations need maintenance: someone follows the announcements and moves the connection to the new version in good time.
Is an API integration secure?
Built properly, yes. Keys must be stored securely, only the permissions needed should be granted, every transfer should be logged and incoming notices verified. That is why we recommend designing security into the first step of the build.
Who owns the integration’s source code?
That is settled in the contract. We recommend writing in that the source code is handed over to you on delivery. That way, should you want to work with another team later, you have a complete and documented system.
If you would like to talk about where to start connecting your systems, see our automation and integration page, or write to us with a short list of the software you use. We reply within two working days.