What API integration actually costs.

The three cost bands

One-way pushes (website form to CRM, orders to email, jobs feed to site) sit around £2,000 to £6,000 when both systems have documented APIs. Two-way synchronisation with logic (stock levels driving availability, CRM stages driving site content, account pricing) runs £6,000 to £20,000. Systems work against legacy software, government schemes or migrations starts above £20,000 and is priced after technical discovery, not before.

Our software and AI engagements start at £18,000 because most client integration work lands in the second and third bands once the real requirements surface. Smaller first-band connections are scoped individually.

The bands are set by direction and authority, not by the number of systems involved. One-way means one system decides and the other listens, so there is never a conflict to resolve. Two-way means both can change the same fact, which forces you to decide who wins, what happens to the loser's version, and how anyone finds out a decision was made. That single question is most of the price difference between the first band and the second.

Why is a two-way sync so much more expensive than a one-way push?

Because a one-way push has one failure mode and a two-way sync has a category of them. If a form submission fails to reach the CRM, you retry it. If a customer record is edited in both systems within the same minute, there is no retry that fixes it — somebody has to have decided, in advance, which version is the truth and what happens to the other one.

Multiply that by every field that both systems can write to, and the work stops being integration and becomes business rules. That is why two-way projects are priced after someone has sat with your team and written those rules down, and why anyone quoting one from a feature list is guessing.

Is it cheaper to use Zapier or Make instead?

For genuine first-band work, often yes, and we will say so. A form that needs to create a CRM contact and send a notification is a job for an automation platform, and paying for custom engineering to do it is waste. The monthly fee is small and the setup is hours rather than weeks.

The ceiling arrives faster than people expect. Automation platforms struggle where you need transactional guarantees, real error handling, complex conditional logic, high volume, or an audit trail that satisfies a regulator. The tell is when your automation has grown to fifteen steps with branches and someone has started keeping a spreadsheet of what it does — at that point the cheap option has quietly become the expensive one, and it is unowned.

What actually drives the price

The API itself is usually the cheap part. Cost concentrates in four places: edge cases (what happens when stock is negative, a record conflicts, a payment half-completes), data quality in the existing systems, authentication and security review cycles, and who owns failures in production.

A worked example from our own products: LoadSnap integrates with DEFRA's Digital Waste Tracking. The government API is documented; the engineering effort went into compliance workflows, failure handling for offline operators and the audit trail. That pattern, where the integration is 20% of the work and the operational reality is 80%, repeats everywhere.

Why does data quality cost so much?

Because an integration exposes every inconsistency your team has been quietly working around for years. The same customer entered three times with different spellings, a phone number field containing notes, a required field left blank since 2019 — all of it is invisible while humans are reading the records and fatal the moment software has to match them automatically.

The cost is not in writing the matching logic, it is in the decisions. Somebody in your business has to say which of the three duplicate records is real. No engineer can make that call, so the project stalls until they do. Budget time for it explicitly, and nominate the person before the build starts rather than discovering mid-project that nobody owns the data.

What does a legacy system add to the cost?

Legacy usually means one or more of: no documented API, no test environment, a vendor who charges for access, and nobody left in the business who knows how it works. Each of those adds discovery time before a single line of integration code is useful.

The expensive version is when there is no API at all and the data has to be reached another way — a nightly file export, a direct database read, or a scheduled report. These work, and we build them, but they change the shape of the project: the freshness guarantees weaken, the failure modes multiply, and the thing needs monitoring in a way an API integration does not.

Questions that scope an integration honestly

Answer these before asking anyone for a price, and the quotes you receive will actually be comparable.

The one people skip is the last, and it is the most important. An integration that works perfectly but changes nothing about how the business operates has cost you money to produce a tidier version of the same problem. Being able to state what stops happening — the rekeying, the Monday morning export, the email chain — is how you know the project is worth running and how you will know afterwards whether it worked.

• Which direction does data flow, and how fresh must it be (real-time, hourly, daily)?
• What should happen when either system is down or returns garbage?
• Who fixes a failed sync at 9am Monday, and how do they find out?
• Is there historical data to migrate, and who owns its quality?
• Which system is the source of truth when both have changed the same record?
• What changes in the business process once this works?

What does an integration cost to run once it is built?

Three ongoing lines, none of them usually large but all of them real: hosting or execution costs for whatever runs the sync, any per-call or per-seat fees from the APIs involved, and maintenance when either side changes. Budget a few hundred pounds a year for a simple connection and low thousands for something business-critical with monitoring.

The line people forget is version changes. APIs deprecate endpoints, rotate authentication and change response shapes, usually with notice and occasionally without. An integration nobody owns will work for eighteen months and then fail on a Tuesday for reasons that take a week to diagnose, because the person who built it has moved on.

Why we price after discovery

Fixed quotes from feature lists are fiction in integration work. We run a short technical discovery against your actual systems, then itemise the build, which is why the number we give is one we keep. The same studio that designs your site builds the integration, so there is one accountable scope rather than an agency blaming a dev shop.

Discovery is deliberately cheap and deliberately real. It means connecting to your systems with test credentials, pulling actual records rather than reading documentation about them, and finding the surprises while they are still cheap. Every integration has at least one, and the difference between a project that lands on budget and one that does not is almost always whether the surprise was found in week one or week six.

You keep the output whether or not you proceed. A discovery document that says "this is a £9,000 project, here is why, and here are the two decisions your team needs to make first" is useful even if you take it elsewhere, and it is a far better basis for comparing quotes than a brief written before anyone looked at the systems.