Systems Integration Services UK

Systems integration versus a single API connection

Connecting your shop to Xero is an API integration. Systems integration is what happens when there are five or ten systems, each holding part of the picture, and they need to behave like one. Ecommerce, ERP, accounts, CRM, warehouse management, a field service app and an old in-house database are a typical mix for a growing UK manufacturer or wholesaler.

The technical work is similar. The difference is design. With many systems, the question isn't "how do I call this API?" but "which system is the master for customers, products, prices, stock and orders, and how does everything else stay in step with it?" Get that wrong and the integrations will copy errors around faster than staff ever could.

Start with a data ownership map

Before writing code we produce a map that answers, for every important type of record:

• Which system owns it. For example, the ERP owns products and stock, the accounts package owns invoices and payments, and the CRM owns leads and contacts.
• Who needs a copy, and how fresh it must be: real time, every few minutes, or nightly.
• Which fields go where, and how codes are translated (VAT rates, nominal codes, product SKUs, customer references).
• What happens on conflict, such as a customer editing their address in the shop while staff edit it in the CRM.

This map often uncovers problems that were invisible: two systems both believing they own pricing, or product codes that don't match. Fixing the data model is cheaper now than after go-live, and sometimes it needs a data migration to clean up first.

Hub and spoke, not spaghetti

Many businesses end up with point-to-point links: the shop talks to the accounts, the accounts to the CRM, the CRM to the email tool, plus scripts and Zapier steps filling the gaps. With ten systems, point-to-point can mean dozens of connections, each with its own failure mode.

We usually build a central integration service instead. Each system connects to the hub once. The hub holds the mappings, applies the business rules and passes messages through a queue (Redis or RabbitMQ, depending on volume). Benefits:

• One place to see every data flow, every error and every retry.
• An outage in one system just leaves messages waiting in the queue; nothing is lost.
• Adding a new system, such as a marketplace or a new warehouse, means one new connector, not five.
• Business rules live in one codebase with tests, not scattered across tools.

For a smaller estate, a hub can be overkill and two well-built direct integrations are the right answer. We'll recommend the simplest design that will hold up.

Legacy and awkward systems

Not everything has a clean REST API. We regularly integrate with:

• desktop or on-premise software that only exposes a database, where we read via views or a replica and write through supported import routes;
• systems that exchange CSV, XML or EDI files over SFTP on a schedule;
• SOAP web services, still common in logistics, finance and public-sector suppliers;
• procurement platforms using OCI punch-out, which we first built for VirtueMart on Joomla.

Where an old system is the bottleneck, integration can be the first stage of legacy modernisation: wrap it, connect it, then replace it without a big-bang cut-over.

Signs you need systems integration, not another tool

Businesses usually come to us when the workarounds have become a job in themselves. Typical signs:

• someone's role is mostly copying data between systems, and holidays cause backlogs;
• month-end reconciliation takes days and still ends with unexplained differences;
• you've added a new sales channel and the manual work grew with it;
• a script or automation written by a former employee runs something important, and nobody dares touch it;
• management reports are compiled by hand from several exports.

Buying another app rarely fixes this, because the problem is between the systems, not inside one of them. Integration fixes the joins.

Delivery, monitoring and ownership

Larger integration projects are delivered in phases so value arrives early. A typical first phase connects orders to accounts; later phases add stock, CRM and reporting. Each phase gets its own fixed price after the free chat and scoping stage.

We run new integrations alongside existing manual processes until a reconciliation report shows the systems agree. Then we switch off the manual step. You receive the code, a runbook explaining how to diagnose common failures and a monitoring dashboard. You own everything. For ongoing monitoring and updates when providers change their APIs, see dijitul support. Joining up data for reporting is covered on our dashboard and reporting page.

What we deliver

• A data map showing every system, which records it owns and how data should flow
• An integration hub or middleware service that brokers all the connections
• Connectors for each system: API, database or file-based
• Queue-based processing with retries and dead-letter handling for failures
• A monitoring dashboard and alerts
• A reconciliation report proving the systems agree
• Technical documentation and a runbook for your team

How it works and what it costs

Every project gets a fixed-price quote after a free initial chat and a short scoping stage. You own the code and the data.

1. Free chat

   Tell us the problem in plain English: what you do now, what goes wrong and what "better" looks like. No charge, no obligation.

2. Scoping

   We map the processes, systems and data involved, agree what is in and out, and write it down so there are no surprises.

3. Fixed-price quote

   You get a fixed price for the agreed scope, or a phased plan for bigger builds, so you can start small and prove it works.

4. Build and test

   We build in short stages you can see and try, test against real data, then go live carefully with a rollback plan.

5. Hand over and look after

   You own the code and the data. We can host it, support it and keep improving it, or hand it to your own team.

Related