Integration is where most business technology projects either save real money or quietly fail. The vocabulary makes it sound more mysterious than it is.
What an API is
An API is a defined set of requests one system will accept from another. Think of it as a menu rather than a doorway.
Your accounting package might accept: create an invoice, list customers, show me payments since a date. It probably will not accept: change this invoice's date after it has been filed, or delete a customer with transactions.
The menu is the point. It is what makes integration safe — another system can only do what the menu permits, so it cannot corrupt anything by accident.
It is also why "it has an API" is not the answer to whether two systems can be connected. The real question is whether the menu contains the item you need.
The two directions
Asking — your system requests information. Fetch today's orders. Get this customer's balance. Simple, predictable, and you control when it happens.
Being told — the other system notifies you when something happens. A payment succeeded. An order shipped. These are webhooks, and they arrive whether you are ready or not.
Most useful integrations need both.
Polling versus webhooks
Polling means asking repeatedly. Every five minutes, are there new orders? Simple to build and reason about. Wasteful, because most answers are "no", and it introduces delay — an order placed at 10:01 is not seen until 10:05.
Webhooks mean the other system calls you the instant something happens. Immediate and efficient, and it requires an address on the internet that reliably receives them.
Webhooks have a complication worth knowing about: they arrive more than once. Networks fail, senders retry, and the same "payment received" notification can arrive twice. If your system creates an invoice each time, you now have two.
Handling this properly — recognising a repeat and ignoring it — is one of the clearest markers of a well-built integration.
Assume every notification will arrive twice, out of order, and occasionally three days late. Integrations built on that assumption survive; the others cause reconciliation work forever.
Why integrations break
Credentials expire
Access tokens have lifetimes and refresh cycles. An integration that authenticated once and never handled renewal stops working, usually on a bank holiday.
The supplier changes something
APIs are versioned, and old versions are retired. Reputable suppliers give notice; the notice goes to an email address nobody monitors.
Rate limits
Suppliers cap how many requests you may make. Exceed it and requests are refused. A migration that pushes ten thousand records will hit this immediately unless it paces itself.
Data that does not fit
A customer name with an apostrophe. A phone number containing a comment. An address with five lines where the other system allows four. Real business data is messier than any specification.
What separates a good integration from a fragile one
The difference is entirely in how failure is handled.
Retries with backoff. If a request fails, try again after a pause, then a longer pause. Most failures are transient.
Somewhere to put what failed. A record that cannot be processed goes in a queue for a human, not into the void.
Alerts to a person. Not a log file. If the integration has been failing for a week, somebody should have known on day one.
Logs you can search. When a customer says their order did not come through, you need to see what happened to it.
Repeat protection. As above — the same event twice must not produce two invoices.
These are unglamorous and they are what you are paying for. An integration that works on a good day is easy; one that behaves sensibly on a bad day is engineering.
Questions to ask before assuming it is possible
- Does the API expose the exact fields I need, including custom ones?
- Can it write, or only read?
- Are there webhooks, or must I poll?
- What are the rate limits, and are they enough for my volume?
- How does authentication work and how often must it be renewed?
- What does it cost — some suppliers charge for API access or for a higher tier?
- How much notice is given before breaking changes?
Answering these before committing prevents the common and expensive discovery that the connection you assumed was straightforward requires an entirely different approach.
When not to integrate
If two systems exchange five records a week, a person copying them is cheaper and more reliable than an integration nobody maintains. Automate volume and frequency, not principle — the argument is made properly in when not to automate.
Our integration team connects business systems for UK companies, with retries, alerting and a queue for what fails. Start a conversation if you have two systems that should be talking and are not.
