Most businesses do not have a software problem. They have a joining-up problem. The finance system knows what was invoiced, the CRM knows what was sold, the warehouse system knows what shipped, and somebody spends their Friday afternoon making the three agree with each other.
API integration is how you stop doing that by hand. This guide explains what it is, how it works, what it costs, and how to judge whether a particular integration is worth building.
What is API integration?
API integration is the process of connecting two or more software systems through their APIs so that data passes between them automatically, without anyone copying it across.
An API, or application programming interface, is a defined set of instructions a piece of software publishes so other software can interact with it. It is the difference between a system you can only use through its screens and a system other tools can talk to directly. When your accounting platform publishes an API, it is effectively saying: here is how to ask me for an invoice, here is how to create a customer, and here is the format I expect.
An integration is the piece of software that has those conversations on your behalf. It authenticates with each system, requests or sends the right data at the right moment, translates between the two formats, and deals with the situations where something does not go to plan.
The important thing to understand is that an API makes integration possible, but it does not make it automatic. Two systems both having good APIs does not mean they work together. Something still has to be built, tested and maintained in between.
How does API integration work?
Most integrations follow the same five stages, whether they connect two systems or ten.
1. Authentication
Before anything moves, each system has to know the integration is allowed to act. In 2026 this is usually OAuth 2.0, where the platform issues a token that can be scoped to specific permissions and revoked without changing anyone's password. Simpler or older systems may use API keys instead. Either way, credentials belong in a secrets store, never in the code itself.
2. Data mapping
This is the stage that decides whether an integration succeeds, and the stage most often rushed. Two systems almost never describe the same thing the same way. One calls it a customer, the other an account. One stores a single name field, the other stores first and last separately. One expects dates as 10/08/2026, the other as 2026-08-10. Mapping is the work of deciding, field by field, what becomes what, and what should happen when a value is missing or does not match anything.
3. Triggering
Next you decide when data should move. There are broadly two options.
Webhooks are event driven. The source system notifies your integration the moment something happens, so an invoice appears in your accounting platform seconds after the order is placed. This is the right choice when timeliness matters.
Scheduled synchronisation runs on a timer, perhaps every fifteen minutes or overnight. It is simpler, easier to reason about and gentler on API rate limits, which makes it a better fit for reporting data or bulk records where a delay costs nothing.
Many integrations use both: webhooks for events that need to be immediate, and a scheduled reconciliation pass to catch anything the webhooks missed.
4. Transformation and transfer
The integration reshapes the data into the format the receiving system expects and sends it. Well built integrations are idempotent at this point, meaning that if the same message arrives twice, you get one record rather than two. This matters more than it sounds, because retries are normal and duplicate invoices are not.
5. Error handling and monitoring
APIs fail. Platforms go down for maintenance, rate limits are hit, tokens expire, and occasionally a record contains something nobody anticipated. The question is not whether this happens but what happens next.
A properly built integration retries transient failures with a backoff delay, holds genuinely bad records in a queue rather than discarding them, logs every transaction so you can prove what moved and when, and alerts a human when something needs attention. An integration that fails silently is worse than no integration, because you will keep trusting data that stopped updating three weeks ago.
When is an API integration worth building?
Not every manual process justifies an integration. In our experience the strongest cases share at least two of these characteristics.
The task is repetitive and frequent. Something done fifty times a day is a far better candidate than something done twice a month.
The same data is entered more than once. Duplicate entry is not just slow, it guarantees the two systems will eventually disagree.
Errors are expensive. Rekeying a payment reference or a delivery address has consequences that go well beyond the few minutes it took.
Delay causes problems. If your sales team cannot see whether an invoice was paid until the next morning, they are having the wrong conversations with customers.
The volume is growing. Manual processes have a ceiling. If your transaction volume doubles, headcount should not have to.
Conversely, be cautious when the process changes shape constantly, when it happens rarely, or when the underlying business rules have not been agreed. Automating a process nobody has defined simply produces wrong answers faster.
Common integration methods compared
APIs are the preferred route, but they are not the only one, and part of scoping an integration is deciding which method actually fits.
REST APIs are the default for modern platforms. They are well documented, widely understood and work over standard HTTPS. Almost all the integrations we build for UK businesses use REST.
Webhooks complement APIs rather than replacing them. They push notifications to you instead of requiring you to poll for changes, which reduces load and latency.
GraphQL allows the client to request exactly the fields it needs in a single call. It is efficient for complex, nested data, though fewer business platforms expose it.
SFTP or file transfer is still common in finance, logistics and payroll, and in dealings with larger enterprises and public bodies. It is unglamorous but reliable, and sometimes it is the only option a counterparty supports.
Database level integration reads or writes directly against a system's database. It should be a last resort, used only where a vendor sanctions it, because it bypasses the application's own validation and tends to break at upgrade time.
Middleware and iPaaS platforms such as Zapier or Make can connect common systems quickly using prebuilt connectors. They are genuinely useful for straightforward, low volume flows. Their limits appear when you need conditional logic, complex transformation, high volume or precise error handling, and when per task pricing starts to exceed the cost of owning the integration outright.
What does API integration cost in the UK?
Cost is driven almost entirely by complexity rather than by which systems are involved. A single, well documented, one directional flow between two modern platforms is a small piece of work. The same integration becomes considerably larger once you add two way synchronisation, conflict resolution, historical data migration, an undocumented or legacy API, or a platform with aggressive rate limits.
The factors that move the number most are the number of systems, whether data flows one way or both, how many fields and records are involved, the quality of the API documentation, whether historical data needs migrating, and how much error handling and reporting you need around it.
Two costs are routinely forgotten at quoting stage. The first is ongoing maintenance: platforms deprecate API versions, change authentication requirements and adjust rate limits, so an integration is a living thing rather than a one off build. The second is the cost of not integrating, which is usually paid quietly in salaried hours and correction work.
For a detailed breakdown of how project scope translates into cost, our guide to what custom software actually costs covers the same principles in more depth.
Security and compliance considerations
An integration moves data across a boundary, which makes it a security consideration rather than purely a technical one.
Apply least privilege. If an integration only needs to read invoices, it should not hold a token that can delete customers. Scoped API credentials exist precisely for this.
Store credentials properly, in a secrets manager or environment configuration, never committed alongside the code.
Send everything over TLS, and treat any API endpoint offered over plain HTTP as unusable.
Minimise what you move. Under UK GDPR you should transfer only the personal data the process genuinely requires. Copying an entire customer record between systems because it was easier than selecting fields is difficult to justify if you are ever asked to.
Log for audit, but not indiscriminately. You want a record of what moved and when, without writing personal data or credentials into log files that have a longer retention period than the data itself.
Understand where the data ends up. If an integration routes through a third party platform hosted outside the UK, that is a processing arrangement you need to be able to document, including the transfer mechanism relied upon.
These controls align with the Cyber Essentials scheme's expectations around access control and secure configuration, which we apply as a Cyber Essentials certified organisation.
Four mistakes we see repeatedly
Mapping the data after starting the build. Field mapping is a business decision disguised as a technical one. Agreeing it upfront, with whoever owns the process, prevents most rework.
No plan for failure. Teams test the path where everything works and ship it. The integrations that cause real damage are the ones that fail quietly and are trusted anyway.
Ignoring rate limits. Most platforms cap how many calls you can make. An integration that works fine against test data can hit that ceiling on the first busy Monday.
Nobody owning it. Six months later the token has expired, the API version is deprecated, and the person who commissioned it has changed role. Every integration needs a named owner and a monitoring alert that reaches a human.
How Synergi Tech approaches integration
We deliver integration as an end to end service rather than a handover of code. That starts with discovery, where we map the process you want to automate and confirm what each system can actually support, because API documentation and API behaviour are not always the same thing.
From there we build the integration with authentication, transformation, retry logic and logging included as standard, test it against real edge cases rather than only happy paths, and monitor it once live so a failure produces an alert rather than a surprise.
We work regularly with the platforms UK businesses run on, including Xero as approved Xero developers, Sage, QuickBooks, payment providers, CRM platforms and bespoke in house applications. Where the right answer is a middleware tool rather than a custom build, we will tell you that too.
If you have two systems that should be talking to each other, our software integration services page sets out how we scope and deliver that work, or you can get in touch to talk through your specific systems.
Frequently asked questions
What is API integration in simple terms?
API integration is connecting two software systems so they can exchange data automatically. Each system publishes an API, which is a defined way for other software to interact with it, and the integration is the piece of software that uses those APIs to move and translate data between them without anyone copying it by hand.
How does API integration work?
An integration authenticates with each system, usually using OAuth 2.0 or an API key, then maps the fields in one system to the equivalent fields in the other. It is triggered either by a webhook when an event occurs or on a schedule, transforms the data into the format the receiving system expects, sends it, and logs the result. Good integrations also retry transient failures and alert someone when a record cannot be processed.
How long does an API integration take to build?
A single, well documented, one directional flow between two modern platforms is typically a short piece of work measured in days. Integrations involving two way synchronisation, several systems, historical data migration or a poorly documented legacy API take considerably longer. The variable that changes the timeline most is not the coding but how quickly the field mapping and business rules can be agreed.
How much does API integration cost?
Cost is driven by complexity rather than by which systems are involved. The main factors are the number of systems, whether data flows one way or both, the volume of records and fields, the quality of the API documentation, whether historical data needs migrating and how much error handling is required. You should also budget for ongoing maintenance, because platforms change their APIs, authentication requirements and rate limits over time.
What is the difference between an API and an integration?
An API is the interface a system publishes so other software can interact with it. An integration is the software that actually uses those interfaces to move data between systems. Two systems both having excellent APIs does not mean they work together, because something still has to be built, tested and maintained in between.
Can I use Zapier instead of building a custom integration?
Often, yes. Middleware platforms such as Zapier or Make connect common systems quickly using prebuilt connectors and are a sensible choice for straightforward, low volume flows. They become limiting when you need conditional logic, complex data transformation, high volumes, precise error handling or reliable auditing, and per task pricing can eventually exceed the cost of owning a custom integration.
What happens if an API integration fails?
That depends entirely on how it was built. A well built integration retries transient failures with a backoff delay, holds records it cannot process in a queue rather than discarding them, logs every transaction, and raises an alert so somebody investigates. A poorly built one fails silently, which is the more dangerous outcome because the data looks current when it is not.