How Much Does a Business API Integration Cost?

What an API integration may cost

When planning an API integration, consider the systems involved, the data and workflows to connect, and the reliability and support your business needs. As an initial guide, one supplier’s published examples put simpler one-way connections below more involved two-way or legacy-system work. ^{1, 2} Web Hero’s UK pricing guide, published 18 March 2026, gives indicative prices of roughly £2,000 to £6,000 for one-way connections between systems with documented APIs, £6,000 to £20,000 for two-way synchronisation with business logic, and above £20,000 for work involving legacy systems, government schemes or migrations. ^{1, 2} These are one supplier’s published examples, not a universal market rate. ^{1, 2}

Use those figures as a prompt to define your own scope, not as a quote or a reliable budget for every project. A connection that copies approved customer details from one system into another has different requirements from one that also updates records in both systems, applies business rules and handles errors without creating duplicate or incomplete records. The systems’ access arrangements and documentation, the volume and condition of the data, and the consequences of a failed transfer can all affect the work.

A supplier’s estimate may include access checks and discovery, mapping which fields and events move between systems, implementation, testing, and deployment. Ask what is included at each stage: for example, whether testing covers failed transfers and duplicate records, and who resolves access problems with either software provider. The initial build is also distinct from ongoing monitoring, maintenance and support, which should be considered separately.

For an early planning estimate, ask suppliers to show the estimated effort and the supplier’s day rate as named inputs, rather than relying on a headline total alone. Then compare what each estimate assumes about data, workflows, testing, deployment and ongoing operation. This makes it easier to see whether a lower figure reflects a genuinely simpler integration or leaves important work out of scope.

How to interpret published price benchmarks

Published prices are useful as a sense-check, but they are not a quote for your systems or workflow. Web Hero’s UK pricing guide, published 18 March 2026, gives indicative prices of roughly £2,000 to £6,000 for one-way connections between systems with documented APIs, £6,000 to £20,000 for two-way synchronisation with business logic, and above £20,000 for work involving legacy systems, government schemes or migrations; these are one supplier’s examples, not a market survey or universal price list. ^{1, 2}

When assessing an integration, consider its scope rather than simply counting the systems involved. A one-way transfer moves information in one direction, such as sending an order from a sales system to an accounting package. Two-way synchronisation may need to decide what happens when a record changes in either system, which system takes precedence, and how conflicts or duplicate records are handled. That business logic needs to be agreed before a supplier can estimate the build reliably.

Work involving a legacy system, a government scheme or a migration may have different unknowns to resolve. A supplier may need to establish what access is available, how the existing data is structured, and whether the required workflow can be supported. The headline category alone does not tell you which of these tasks is included, or how much investigation your own project needs.

When comparing a published example with a proposal, check whether both cover the same stages. Ask whether the price includes discovery and access checks, mapping fields and workflows, cleaning or correcting data, building the connection, testing with realistic records, deployment, documentation and monitoring. Clarify whether ongoing support is included or priced separately. A figure that excludes testing or deployment is not directly comparable with one that includes them.

Ask each supplier to write down the assumptions behind the estimate: which systems and data flows are in scope, what access or documentation they expect you to provide, and what they have excluded. Also ask what would trigger a change to the scope—for example, discovering that a required data field is unavailable, or that an agreed workflow needs extra handling. You can then compare proposals by the work they commit to deliver, rather than choosing on a headline figure that may cover a different integration.

Where the one-off integration cost goes

A useful quote separates the work needed to understand the systems, agree what should happen to the data, build and test the connection, and put it into operation. These stages do not take the same effort on every project: some may be brief, combined or unnecessary, depending on the systems and the agreed scope.

For a first estimate, use estimated effort in days × the supplier’s day rate. This is a planning formula, not a complete project cost on its own. It assumes the effort relates to a defined scope and that you have checked which stages, supplier roles, testing, deployment and handover the rate or estimate includes. Confirm whether discovery is included, how scope changes are priced, and whether third-party charges or ongoing support sit outside the estimate. Effort and exclusions should be stated clearly enough for you to see what you are comparing.

What makes an integration quote higher or lower

The main cost drivers are how much access the systems allow, how clean and compatible their data is, and how many decisions the integration must make when records change or something goes wrong. A narrow, one-way transfer between well-understood systems is generally simpler to scope than a two-way workflow with exceptions, duplicate handling and operational support requirements.

System access and documentation. Before estimating the build, establish who can provide access to each system and what kind of access is available. A supplier may need test credentials, a safe test environment and current API documentation to confirm which records and actions can be reached. If access must be arranged through a system administrator or third-party provider, or the available documentation leaves important behaviour unclear, the supplier may need additional investigation before the scope is firm. Ask what access the business must arrange and whether the quote includes checking that access.

Data quality and mapping. Two systems may describe the same business information differently. For example, one may store a customer's name and address in separate fields while another uses a single contact record; a product code in one system may not match the identifier used in the other. The business needs to decide which system is authoritative for each field, what to do with missing or inconsistent values, and whether existing records need tidying before transfer. If those decisions are left until build or testing, extra mapping, exception handling and rework may be needed.

Workflows and rules. Count the actions the integration must support, not just the systems involved. Sending a new order from an online shop to an accounts system is a different scope from also sending updates, cancellations, refunds and stock changes back the other way. Each additional workflow raises questions about timing, which record wins when values conflict, and what happens when a record is changed in both places. Duplicate handling also needs a clear rule: should the integration update an existing record, create a new one, or flag it for a person to resolve?

Failure handling and platform constraints. A connection can be interrupted, a required field may be missing, or a destination system may reject a request. Agree whether the integration should retry, stop and alert someone, or send the item to a queue for review. Where staff need to correct an error, specify what information they will see and how the corrected record is resubmitted. For Xero, its official developer FAQ says API requests that exceed a rate limit receive an HTTP 429 response, a platform constraint to check when scoping an integration with Xero.³ Ask the supplier to explain how any relevant platform limits affect the planned volume and handling of delayed requests.

Testing, deployment and reliability. The business should identify who will check that transferred records are accurate, which real-world cases need testing, and who approves the integration for use. Testing more workflows and edge cases takes more effort, but can expose problems before staff depend on the connection. Agree how deployment will be coordinated, how issues will be surfaced, and what monitoring or support is included after launch. Requirements for prompt alerts or regular review should be scoped explicitly rather than assumed to be part of the build.

When comparing estimates, ask suppliers to show which of these assumptions they have made. A quote is easier to assess when it distinguishes confirmed access and data conditions from items that still need investigation, and explains how a change in workflow or reliability requirements would affect scope.

Budget for running the integration after launch

The build quote covers getting the integration ready to use; it does not necessarily cover the work of keeping it useful afterwards. Budget separately for ongoing monitoring, maintenance, investigating failures, adapting to changes in connected systems and any new workflow changes you request.

Monitoring means checking that the agreed data transfers are working and that failures are visible. Maintenance may involve investigating a failed transfer, correcting an issue and checking that data is handled as intended afterwards. Changes to either connected system can also mean the integration needs attention, even if your own process has not changed.

Agree what happens when something goes wrong. For example, if an order fails to appear in the system used by your fulfilment team, decide who receives the alert, who investigates it, and who tells staff whether they should enter or correct the information manually. Clarify whether the supplier monitors the integration, whether your staff must report problems, and what response and support arrangements are included. Do not assume that monitoring and hands-on support are the same service.

Ask the supplier to distinguish routine monitoring and maintenance from work caused by a change to a connected system or a new business requirement. Establish how such work is assessed and approved before it begins. If your team changes a field, status or approval step, for instance, that may require a separate scope decision rather than being covered by ongoing support.

Third-party service charges may also apply, depending on the systems and services involved. Ask the supplier to identify any such charges, say whether they are included in the proposal, and clarify who pays them. Also check whether usage or storage needs could affect what you pay to other providers.

There is no single ongoing budget that suits every integration. It depends on usage, system changes, the support you expect and how important it is for the workflow to keep operating. Ask for the ongoing arrangement to be described separately from the one-off build, including what is covered, what is excluded and how additional work is handled.

How to compare integration quotes fairly

Compare proposals against the same written brief, not just their headline totals. A lower figure may cover fewer workflows, less testing or no post-launch support, so ask each supplier to confirm what they have priced and what remains your responsibility.

• Systems and workflows: Ask each supplier to name the systems being connected and describe the same business processes. For example, specify whether a new order moves from the sales system into fulfilment, and whether changes or cancellations must also be passed back.
• Direction and data: Confirm which records and fields move, in which direction, and what should happen when information is missing or different between systems. A proposal that covers one-way transfer is not directly comparable with one that includes updates in both systems.
• Stages included: Check whether the proposal includes discovery and access checks, data and workflow mapping, implementation, testing, deployment and handover. Ask what testing covers, who checks the results, and what documentation or staff guidance is included.
• Assumptions and dependencies: Look for stated assumptions about access to each system, the condition of existing data, transaction volumes, third-party services and your staff’s availability. Confirm who will arrange access, provide sample records, make decisions and carry out business testing.
• Ongoing responsibilities: Separate the one-off work from any monitoring, maintenance or support. Establish who investigates failed transfers, makes changes when a connected system changes, and pays any third-party charges; do not assume these are included in the build.
• Exclusions, risks and changes: Ask each supplier to list work not included, dependencies that could delay or alter the work, and known risks. Find out how a request to add a workflow or change a rule will be assessed and agreed, including how its effect on the estimate will be explained.
• Unclear scope: Ask for clarification where a proposal uses broad terms such as “testing” or “support” without defining them. Have any agreed clarification recorded so you can compare the same scope across proposals rather than relying on what you assume a headline figure covers.

A useful comparison records each supplier’s inclusions, exclusions, assumptions and ongoing responsibilities against the same brief. If proposals still differ, ask what specific scope or assumption accounts for the difference before deciding which is the better fit.

What to include in an enquiry to an integration supplier

A useful enquiry gives suppliers enough information to estimate the same job, rather than asking them to price a vague request to “connect two systems”. You do not need a complete technical specification: describe the workflow, the information involved and the decisions still to be made.

• Systems and contacts: Name each system, explain what your business uses it for and identify who can arrange access or answer questions. Note whether an internal owner, existing supplier or system administrator needs to be involved.
• Current problem and intended outcome: Describe what staff do now, such as copying order details from one system into another, and where duplicated records or delays arise. State what should happen instead and who will use or rely on the result.
• Information to exchange: List the main records and fields involved, such as customer details, orders or stock information. Say which system is the source for each item and whether data moves one way or both ways. Flag information that should not be transferred.
• Timing and business rules: Explain when information needs to move: after a particular action, on a schedule, or only when someone approves it. Describe rules that change the outcome, such as how to handle a cancelled order, an existing matching record or a missing field.
• Exceptions and data quality: Tell the supplier about known inconsistencies, duplicate records and incomplete data. Explain what staff should be able to see or do if a transfer fails, and who should investigate and correct the underlying record.
• Testing and operation: Say how the business will confirm that the information is accurate and the workflow works as intended. Identify who can provide realistic test cases and approve the result. Describe the operational arrangement you need, including who should receive failure notifications and handle system or workflow changes.
• Estimate and boundaries: Ask for discovery and access checks, implementation, testing and deployment to be shown separately. Request ongoing monitoring and maintenance costs separately from one-off work, and ask the supplier to state assumptions, exclusions, third-party dependencies and how changes to scope would be handled.

Where details are unknown, say so and ask the supplier to identify them as questions or assumptions rather than silently building them into an estimate. This makes it easier to see which decisions may change the scope before you compare proposals.

When a custom integration may not be necessary

A custom API integration is not always the right first step. Start by defining the business outcome: for example, whether a new customer record needs to appear in another system, or whether staff need to stop re-entering order details. Then check whether the systems already offer a built-in connection or an existing workflow that meets that need.

A built-in option may be sufficient if it moves the required information and supports the way your team works. Check which records it transfers, when updates happen, and how it handles errors or changes. A connection that syncs only some fields, for instance, may leave staff with manual checks or duplicate entry.

Manual transfer can remain reasonable when it happens infrequently, the consequences of delay or error are manageable, and someone can reliably complete and check it. Be clear about its limits: who enters the information, how they spot mistakes, and what happens when that person is unavailable. If the process is frequent, difficult to check or creates material operational risk, those limitations may outweigh the cost of a more automated approach.

Compare the available options against the outcome you need, including their practical limits and ongoing responsibilities. If simpler approaches cannot support the required workflow, consider exploring a scoped custom integration rather than commissioning one by default.