How Much Does Software Integration Cost? APIs, Legacy Systems, and Hidden Work

Your business already has software for managing customers, scheduling work, tracking inventory, or sending invoices. You are not necessarily looking to replace any of it. You just need the applications to exchange information without someone entering the same details twice.

The visible task might sound small: send completed work orders to billing, copy approved customer changes into another application, or bring several systems together for reporting. The estimate needs to cover more than moving a few fields. It also needs to confirm access, determine what the records really mean, handle incomplete or conflicting information, and prove the connection can recover when something goes wrong.

Software integration cost is the cost of making an existing business process work across systems. It is not simply the cost of making those systems communicate.

For perspective, the worked example later in this article uses 260 hours at an illustrative $125 per hour. That produces $32,500 in implementation labor, or a $39,000 planning budget after adding a 20% contingency. These are example calculations, not an industry average or an Honor Tech quote. Vendor charges, internal staff time, and ongoing operation sit outside the example. For current Honor Tech rate bands, see our software consulting pricing.

Your project may require substantially less or more. The useful question is which work the estimate includes and which assumptions could change it.

Start with the business outcome, not the number of connections

Connecting two applications is not a sufficiently detailed scope.

Consider a service-management application sending work orders into accounting. Should it send every completed job, or only jobs approved for billing? What happens to warranty work? Can one job produce several invoices? Can several jobs be combined? What happens when a supervisor reopens a job after accounting has received it?

Those decisions determine the integration's behavior. They also determine its cost.

Define the records, permitted actions, direction of travel, timing, and completion criteria. A nightly feed that creates draft billing records is a different project from a two-way connection that synchronizes customer edits, invoice changes, payments, credits, and cancellations all day.

For two-way integration, assign authority at the field or process level. Accounting might control billing addresses while operations controls service locations. Do not leave the software to resolve conflicting edits through whichever update happened to arrive last unless that is the agreed business rule.

Separate historical loading from ongoing synchronization, too. Starting with new transactions after a defined date does not include cleaning up ten years of records. A historical load also needs a plan for changes made while that load is running.

A useful scope says what the connection will do, what it will deliberately leave alone, and what people must still review. If those answers are not available yet, a bounded workflow and integration assessment can turn the unknowns into a practical plan before a larger commitment.

Do the required API endpoints and import features actually exist?

An application having an API does not establish that it supports your integration.

The source needs to expose the particular information you require. The destination needs to accept the intended action. Being able to retrieve customers does not mean you can retrieve their attachments, update their approval status, or create the accounting transactions associated with them.

Evaluate the actual interfaces: APIs, remote procedure calls, vendor-supported stored procedures, file-transfer feeds, scheduled imports, and other approved endpoints. Identify what exists in the versions and subscription plans your business actually uses, not just in a vendor demonstration.

For each required operation, establish whether the interface can read, create, update, cancel, or otherwise change the right record. Then test the important limitations. Does it expose custom fields? Can it retrieve archived records? Can it identify deletions? Does an import update existing records or only append new ones?

For file exchanges, confirm the format, encoding, transfer method, schedule, and acknowledgment process. An older FTP feed may require an approved secure alternative such as SFTP or FTPS. A successful upload is not proof that the receiving application accepted the file or imported every row.

Also check whether the interface performs the intended business action. Creating a database record and completing an application workflow are not necessarily equivalent. If one product truly has no usable API, there may still be supported options; our guide to connecting business systems without an API walks through the tradeoffs.

Price missing vendor work before committing to the integration

When a required interface is missing, obtain a vendor quote before treating it as available.

The request should describe the required operation, fields, expected volume, authentication, error reporting, and test access. Ask whether the change will be supported through future upgrades, whether recurring charges apply, and when it can actually be delivered.

A proposed feature on a roadmap is not a usable dependency. Neither is an informal assurance that an endpoint should be easy to add.

Treat missing functionality as a decision point. You can purchase the vendor enhancement, reduce the scope, choose another supported route, or compare the cost of replacing the limiting application or workflow.

Custom middleware cannot manufacture access that the vendor does not expose or permit.

Put API access, licensing, and vendor constraints in the budget

Even when the endpoints exist, there may be considerable work between reading the documentation and making an authorized production request.

Ask about API licensing, required plan upgrades, connector subscriptions, partner approval, test environments, and vendor professional-services fees. Determine who provisions access and who is allowed to authorize it.

Then establish the technical access requirements. Does the connection need its own service identity, restricted permissions, a private network connection, an approved IP address, or a client certificate? Who handles credential expiration and rotation? How will test and production credentials remain separate?

Avoid basing the integration on an employee's personal login simply because it works during a demonstration. Price the approved operating arrangement instead.

Usage limits also change the design. Determine request quotas, page sizes, bulk-operation limits, concurrency restrictions, and charges for higher throughput. A daily record count alone does not describe API usage when each record requires several lookups, writes, and confirmation requests.

A connector advertised for both products still needs evaluation. Confirm that it supports your exact records and actions, including custom fields and failure recovery. Include its subscription or usage costs in the comparison rather than assuming a prebuilt connector eliminates implementation work.

Finally, distinguish vendor waiting time from billable engineering time. Waiting two weeks for credentials does not automatically create two weeks of development charges. It can still delay benefits, require repeated coordination, or force the team to restart work later. The estimate and schedule should show those effects separately.

Database access is not the same as understanding the application

A database login can make an integration look straightforward. The tables are visible, the fields appear familiar, and a few sample records seem to follow a pattern.

That is a starting hypothesis, not a verified business specification.

Suppose a status value appears to identify records ready for billing. Does it also include canceled work awaiting cleanup? Is the billable amount stored on the main record, calculated from related rows, or adjusted by an overnight process? Does a timestamp reflect the business event, the last screen edit, or a background update?

If your team did not build the application, budget for answering those questions. Use approved test data or a controlled copy, trace representative workflows, inspect the available documentation, and have knowledgeable users or vendor staff confirm the interpretation.

Where supported, documented reporting views or approved extraction interfaces can provide a clearer boundary than querying internal tables. You still need to evaluate freshness and performance. A reporting copy may lag behind production, and a large read query can burden a live application.

Direct writes deserve a separate, higher-risk decision. Updating a field may not reproduce the application's validation, related-record changes, audit history, or downstream actions. Use a supported write path unless an explicitly approved design proves another route is safe.

When an estimate relies on inferred database behavior, include time for discovering that the inference was wrong. That allowance may cover another investigation, revised mappings, corrected staging data, and repeated testing. Record the assumptions and the evidence needed to validate them. An attractive database shortcut should not quietly become the foundation of a fixed promise.

Data cleanup is a separate workstream

Moving inconsistent data faster does not make it more useful.

Before finalizing the mapping, examine representative records across the locations, departments, time periods, and statuses included in the project. Look for duplicate identities, missing required values, broken relationships, inconsistent codes, and records that cannot be mapped confidently. A sample consisting only of recent, complete records will not tell you what happens to older or unusual ones.

Distinguish formatting problems from business decisions

Some transformations are mechanical once the rules are approved: converting an agreed date format, mapping a known status code, or removing unwanted whitespace.

Other cleanup tasks require judgment. Two customer records sharing an email address are not automatically the same customer. A missing identifier should not be invented to satisfy an import. An empty value may mean unknown, not applicable, or intentionally cleared, so it should not automatically overwrite useful information in the destination.

Preserve identifiers with meaningful leading zeros. Clarify time zones, decimal precision, units, and the treatment of invalid values. Do not silently truncate information merely because the receiving field is shorter.

For recurring integrations, maintain a reliable relationship between source and destination identifiers. Matching every transaction by customer name leaves too much room for a changed spelling or shared name to affect the wrong account.

Decide who resolves records that cannot be mapped safely

The scope should identify who approves transformation rules, who reviews uncertain matches, and who corrects source data. Preserve the original values and enough processing history to explain important changes.

This is also where one-time cleanup and ongoing controls separate. Correcting existing duplicates does not prevent tomorrow's duplicate. Recurring validation needs an agreed response: reject the record, hold it for review, or apply a specifically approved correction.

The amount of human review matters financially. An estimate that includes building a review queue does not necessarily include staff resolving every record in it. Show both responsibilities. For projects where cleanup is a major part of the work, review the separate responsibilities involved in data migration and reconciliation.

Budget for the people who understand each system

Developers need access to people who understand how the applications support the business, especially when another department or vendor manages the systems.

Include time for walkthroughs, preparation, sample selection, follow-up questions, mapping approval, and acceptance testing. The integration team needs answers about exceptional workflows as well as ordinary ones.

A one-hour meeting involving four people consumes four staff-hours before preparation or follow-up. Internal employees may not generate another vendor invoice, but their time still belongs in the project's overall cost and availability plan.

Identify who can make decisions, not only who can describe current behavior. A developer should not have to choose whether a canceled work order reverses a charge or creates a credit because nobody has been assigned to answer.

Capture decisions in a shared workflow description and mapping document. When an answer changes, the team should be able to identify the affected code, data rules, and tests.

Price error handling by failure type

An estimate with a single line for error handling needs more explanation.

A temporary interruption, invalid record, expired credential, and partially completed transaction require different responses. Some failures justify another attempt. Others require a correction, vendor assistance, or human review.

Before estimating the work, inspect the actual error structure. Look for a stable machine-readable code, affected field or row, request identifier, transaction or job identifier, explanatory details, and any retry guidance. Determine whether failures arrive immediately, inside an otherwise successful response, or later through an import report or callback.

Do not classify recovery solely by a broad HTTP status category. The endpoint's behavior and the result of the business operation matter.

Clear, consistent errors can reduce diagnostic work. Vague messages or inconsistent response formats leave more to investigate and support. When a vendor does not provide enough information to determine a safe automated response, price the manual exception path.

A timeout does not prove that nothing happened

Consider an integration that submits a billing record. The receiving system creates it, but the response is lost before the integration receives confirmation.

Sending the request again could create a duplicate unless the interface and integration have an agreed way to recognize the same operation. Where supported, this may involve an idempotency key: an identifier that lets repeated attempts refer to the same intended action. Its scope and retention period must fit the recovery design.

When that support is unavailable, investigate whether a stable external identifier and reliable lookup can confirm the outcome. If the outcome remains uncertain, holding the item for review may be safer than guessing.

The same issue appears with file imports. If part of a batch succeeds, resending the whole file is safe only when the receiving process can recognize work already completed.

Recovery needs an owner and a usable process

A technical log is not a complete recovery procedure.

Someone needs to see which records remain unresolved, understand the business impact, correct what is necessary, and resume processing without duplicating successful work. That may require a small review screen, an exception report, or an existing operations tool. It does not necessarily require a large custom administration portal.

Retain useful identifiers and processing history without dumping credentials or unnecessary sensitive information into logs. Define who can view, correct, and replay records.

For workflows spanning several systems, reversing one database change may not undo actions already completed elsewhere. Identify which steps can be retried, reversed through supported operations, or resolved manually. Price that behavior before launch.

Testing should prove business results and recovery

A successful demonstration confirms that one path worked under the conditions demonstrated. It does not establish that the integration is ready for everyday use.

The testing budget should cover mapping rules, real interface behavior, complete business workflows, and the response to failures. A simulated vendor response can help test your code, but it cannot prove that the vendor's actual endpoint behaves the same way.

Use approved test environments and representative, appropriately protected data. Account for differences between test and production permissions, configuration, limits, and features. Agree on load-testing methods rather than sending uncontrolled traffic to a vendor's service.

Test the situations most likely to change the estimate

Include missing values, ambiguous matches, cancellations, reopened records, duplicate deliveries, and updates arriving in an unexpected order. Exercise permission loss, temporary outages, restarts during processing, and partially accepted batches.

Then test what happens next. Can the connection resume from the right point? Does the same transaction appear twice? Does one rejected item stop unrelated work? Can staff correct an exception without asking a developer to edit production data?

Test peak workloads and catch-up workloads separately. A connection may handle ordinary daily volume yet fall behind after an outage. Establish how quickly it needs to recover and whether vendor limits allow that rate.

Do not promise that every possible edge case has been identified. Prioritize by likelihood and consequence, document the included cases, and retain a process for new discoveries.

Reconcile the records, not just the transfer status

An import completing successfully does not prove that the right information reached the right place.

Compare identities, important field values, relationships, totals, and intended business states. Matching record counts alone is insufficient. Two systems can contain the same number of records while disagreeing about which customers or transactions they represent.

Have business users verify the result inside the receiving application. The record should be usable for its intended next step, not merely present in a table.

Keep these checks repeatable. They are useful during initial testing, vendor upgrades, recovery exercises, and later changes to the integration.

AI-assisted development does not remove responsibility for the integration

AI tools can assist with mappings, clients, tests, and diagnostic utilities. Account for those efficiencies where the team can demonstrate them.

Faster code generation is not a reason to omit investigation, business decisions, review, or end-to-end testing. A tool supplied with an incorrect interpretation of a legacy status field can implement the wrong rule just as readily as the right one.

As the number of workflows and recovery paths grows, there is more behavior to verify and maintain, even when producing individual pieces of code is fast. Someone still needs to provide context, inspect changes, evaluate results, coordinate with vendors, and take responsibility for deployment.

That does not mean billing every hour an automated job runs as active engineering time. Separate hands-on work from unattended processing, waiting, and actual tool or infrastructure charges.

The meaningful saving is a lower cost to deliver a verified result, not simply a shorter time to produce the first implementation.

Use contingency for uncertainty, not omitted requirements

A 20% contingency can be a useful starting point for a planning conversation. It is not a guarantee that the budget is sufficient, and it is not a universal rule.

A narrow integration with working test access and documented behavior is different from one that depends on an undocumented database or an endpoint the vendor has not agreed to build. Greater uncertainty may call for a larger reserve, a narrower first phase, or a paid investigation before implementation can be priced responsibly.

Known testing, failure handling, and vendor coordination belong in the base estimate. They should not be hidden inside contingency.

For each important assumption, describe what happens if it fails. An unsupported historical export may require a different extraction route. Unreliable customer identifiers may require manual matching. A missing write operation may require a vendor change or make the intended design infeasible.

That last case is not necessarily solvable by adding another percentage. Sometimes the right response is to stop, reassess, and obtain approval for a different approach.

State what the reserve covers, how additional work is authorized, and how it relates to the agreed commercial terms. A contingency allowance is not automatically a fee or permission to expand the scope.

An example software integration cost breakdown

Consider a hypothetical nightly connection from an existing work-order application into an existing billing application.

The scope is limited to approved, newly eligible work orders and creation of draft billing records. It uses confirmed, supported interfaces and an agreed customer-matching approach. It includes validation, controlled recovery, and reconciliation. It does not include replacing either application, taking payments, synchronizing every field in both directions, or converting years of historical records.

The following figures illustrate how to expose the work. They are not promised delivery hours, a market survey, or a quote. A real estimate should use the actual tasks, roles, and agreed rates.

In this example, core data-transfer development accounts for $6,000. The remaining base labor addresses what the connection means, how it gains access, how information is interpreted, how failures are handled, and how the result is verified and introduced into use.

Vendor development charges, API access fees, connector subscriptions, hosting, internal staff participation, and ongoing support are not included in the table. Add the applicable amounts explicitly. An unconfirmed vendor fee should be marked as unresolved, not entered as zero.

Keep discovery and coordination distinct so the same meeting or task is not counted twice. Likewise, agree whether existing platform capabilities can replace custom work before assigning hours to build it.

A smaller, proven integration may need far fewer hours. Unresolved vendor development, extensive historical cleanup, or high-consequence workflows can require substantially more. Comparing quotes only makes sense when the included responsibilities are comparable. The broader custom software cost guide covers team structure, deadlines, security, and other pricing factors that may also apply.

Include operating costs and the life of the endpoints

Implementation is one budget. Keeping the integration useful is another.

Plan for the runtime environment, monitoring, retained processing data, credentials, vendor subscriptions, support, and updates. Decide who receives alerts, who investigates missing or delayed records, and what response coverage the business actually needs.

Monitor freshness and expected activity as well as explicit failures. A scheduled exchange that never starts may produce no application error. At the same time, a legitimate day with no eligible records should not automatically become an incident. Define the difference.

Clarify responsibility for vendor changes, new business rules, defects, and user-requested enhancements. These are different categories of work even when they all arrive as support requests. A defined application support and maintenance arrangement can make those ownership boundaries explicit after launch.

Before building, ask whether either application, API version, import format, or authentication method is scheduled for replacement. An integration designed for an interface that will soon disappear needs an explicit useful life and transition plan.

A temporary connection may still be worthwhile when it produces enough near-term value. Keep its scope proportionate, identify what can be reused, and budget to retire it. Separating vendor-specific connection code from approved mapping rules and tests can reduce later rework, but it does not guarantee that a replacement endpoint will be interchangeable.

Is paying the vendor cheaper than building an application?

Sometimes it is. The comparison needs to cover equivalent outcomes over the same period.

For a vendor enhancement, include the vendor's development charge, your integration implementation, recurring access costs, future compatibility work, and the consequences of the delivery schedule.

For a replacement application or focused custom module, include the business functions being replaced, data transition, user training, permissions, reporting, ongoing support, and any integrations that remain necessary.

Replacing one application does not remove restrictions imposed by the other one. A new custom application still needs a supported way to communicate with whatever remains.

Use a defined comparison period and identify which costs are firm, estimated, or unresolved. Include the manual work and errors the proposed change is expected to remove, but do not assume every current staff-hour disappears after automation.

A supported vendor enhancement may preserve applications that otherwise serve the business well. A narrowly scoped custom application may be more reasonable when a workaround requires continuing investigation and repair. The decision should follow the actual costs and constraints, not a preference for building or buying.

Get an estimate that explains what happens when things go wrong

A useful software integration estimate should make three things clear: what has been verified, what is included, and what could change the price.

Look for confirmed access to the required operations, documented data rules, a realistic testing plan, identified recovery responsibilities, and a separate view of vendor and operating costs. Unresolved dependencies should be visible before the project is approved.

When the important unknowns are still about access, database meaning, or vendor cooperation, start with a bounded assessment. The next investment should establish whether the connection is feasible and what delivering it responsibly requires.

Honor Tech helps organizations evaluate and connect existing business systems. Our systems integration services cover APIs, databases, files, vendor platforms, failure recovery, and the operational details around them. If you need to turn an uncertain connection into a scoped decision, tell us about the workflow.

The goal is not the cheapest connection that works once. It is a connection your business can rely on, understand, and recover at a cost you have actually planned for.