Someone will tell you an integration is a two-day job. Sometimes they are right. Reading a customer record out of one system and writing it into another, in the happy path, against a documented API, genuinely is a small piece of work. The reason integration projects come in at ten times that estimate is that the happy path is maybe a quarter of the work, and nobody quotes the other three quarters because nobody sees them in a demo.
This page prices integration the way we actually price it: by how hard the systems on each end make your life, plus the fixed cost of making the connection survivable in production, plus what it costs to keep running once it is live.
What you are actually paying for
The transport is the cheap part. Here is where the hours go on a typical connection between two business systems.
- Mapping the data contract: which system owns which field, what happens when both sides edit the same record, and what an empty value means in each.
- Failure behavior: retries with backoff, poison-message handling, and a decision about whether a failed record blocks the queue or gets parked.
- Idempotency: making sure a retry does not create a second invoice. This is the single most common defect we find in inherited integrations.
- Reconciliation: a scheduled job that compares both sides and reports drift, because eventually the two systems will disagree and you need to know before your finance team does.
- Monitoring and alerting: someone specific gets paged when the sync stops, and the alert says what broke rather than that something broke.
- The edge cases: partial refunds, merged customers, deleted records, timezone handling, records that exceed a field length on the receiving side.
Cost by difficulty tier
Ranges below are for a single directional or bidirectional sync between two systems, delivered by senior US-based engineers, including the failure handling and monitoring described above. The variable that moves the number is almost never your business logic. It is what the other end gives you to work with.
| Tier | What the far end looks like | Typical build cost | Where the time goes |
|---|---|---|---|
| Tier 1: Cooperative | Documented REST API, a sandbox you can hit freely, webhooks for change events, stable versioning. | $8,000 – $20,000 | Data mapping and edge cases. The plumbing is straightforward. |
| Tier 2: Awkward | Documented but polls only, aggressive rate limits, broken or inconsistent pagination, no sandbox so you test against production. | $18,000 – $40,000 | Throttling, checkpointing, and building a safe way to test without corrupting live data. |
| Tier 3: Hostile | Undocumented or stale docs, SOAP or a proprietary protocol, nightly CSV or fixed-width file drops, vendor support measured in weeks. | $25,000 – $70,000 | Reverse-engineering behavior, handling files that arrive late or twice, and absorbing vendor-side changes with no notice. |
| Tier 4: Screen scraping | No API at all. Automating a browser or a terminal session against a UI that was never meant to be a machine interface. | $30,000 – $80,000+, plus high run cost | Session handling, MFA, and rebuilding the automation every time the vendor moves a button. |
Why the second integration is sometimes cheaper
You will hear that integrations get cheaper as you add them. That is only true if the first one was built as infrastructure rather than as a one-off script. The reusable parts are the queue, the retry and dead-letter handling, the credential store, the logging format, the reconciliation harness, and the alerting. Build those once and integrations two through six are perhaps 50–70% of the first one's cost.
Build the first one as a standalone script with its own logging, its own scheduler, and its own idea of what a failure means, and integration seven costs exactly what integration one did. Worse, you now have seven separate things to monitor, seven credential rotations to remember, and no single place to answer the question every operations team eventually asks: is everything in sync right now?
The shared-plumbing decision usually adds $10,000 to $25,000 to the first integration. If you know you have three or more coming, take it. If this is genuinely the only connection you will ever build, skip it and keep the script simple.
The run cost everyone forgets
An integration is not a deliverable, it is a dependency. Both systems on either end will change, and neither vendor will consult you first. Plan on 15–25% of build cost per year, per integration, covering the following.
- API version deprecations, usually on the vendor's schedule with 60 to 90 days' notice.
- Credential and certificate rotation, which breaks things loudly when it is forgotten.
- Schema drift as someone adds a required field to a form on the far end.
- Volume growth pushing you into rate limits that were never a problem at launch.
- Investigation time when reconciliation flags a mismatch, which is normal operational work, not a defect.
- Hosting for whatever runs the sync, typically modest, and iPaaS subscription fees if you use one.
An integration with zero ongoing spend is either brand new or unmonitored. We have inherited plenty of the second kind: green dashboards, no alerts, and eighteen months of records that silently stopped flowing.
A worked example
Illustrative figures for one bidirectional sync we would classify as Tier 2: a field service platform and an accounting system, pushing completed jobs to invoices and pulling payment status back. Roughly 400 records a day. These are our own typical numbers, not a published benchmark.
| Line item | Estimate | Note |
|---|---|---|
| Discovery and data contract | $6,000 | Field-level mapping, ownership rules, conflict behavior |
| Happy-path sync, both directions | $9,000 | The part people think is the whole job |
| Error handling and idempotency | $8,000 | Retries, dead-letter queue, duplicate-invoice prevention |
| Reconciliation job and report | $5,000 | Nightly comparison with a drift report finance can read |
| Monitoring, alerting, runbook | $4,000 | Named owner, actionable alerts, documented recovery steps |
| Cutover and parallel run | $4,000 | Two weeks of both systems running with manual verification |
| Build total | $36,000 | Delivered in 5–7 weeks |
| Annual run cost | $6,000 – $9,000 | Version changes, credential rotation, drift investigation |
The cost of not integrating
This is the number that decides most integration business cases, and it is the one almost nobody calculates, because it is spread across people who are already on payroll.
Take the example above. If two coordinators each spend 90 minutes a day re-keying completed jobs into the accounting system, that is roughly 750 hours a year. At a loaded rate of $40 an hour, the manual process costs about $30,000 annually, and it buys you a typo rate. Add the two days a month someone spends reconciling the two systems at close, and the integration pays for itself inside eighteen months on labor alone.
The labor cost is the easy part to defend. The harder cost is decision quality. When your revenue figure is a day and a half stale, people stop trusting it and start keeping private spreadsheets, and the spreadsheets become the real system of record. That failure mode is expensive and it does not show up on any invoice.
A trades services business replaced fragile ERP integrations with clean connections to accounting, communications, and fleet systems, moving job completion to invoicing into the same day rather than the same week.
How to scope one so the price holds
- 1
Name the systems and get API documentation for both before anyone quotes. Tier is the single biggest cost driver and it is knowable in an afternoon.
- 2
Ask whether a sandbox exists. No sandbox moves a Tier 1 job to Tier 2 and adds real cost, because every test carries production risk.
- 3
Decide field ownership per field, not per system. Most integration disputes are really unresolved arguments about who owns the customer address.
- 4
State the volume and the acceptable lag. Near-real-time and hourly batch are different systems with different prices; nightly is cheaper than both.
- 5
Ask what happens when a record fails. If the answer does not include where the record goes and who finds out, error handling is not in the quote.
- 6
Agree who operates it after launch and fund that. An integration with no named owner degrades quietly until it fails loudly.
Common questions
- How much does one integration cost?
- Between roughly $8,000 and $70,000, depending almost entirely on what the far end offers. A documented REST API with a sandbox sits at the bottom of that range; an undocumented legacy system or nightly file drops sits at the top. Business complexity on your side moves the number far less than the quality of the interface you are integrating against.
- Is an iPaaS platform cheaper than a custom integration?
- For simple, low-volume, well-supported connections it usually is, because the connectors and retry handling already exist. It gets expensive when volume grows, when your logic outgrows the visual builder, or when per-task pricing scales with your business. The honest comparison is subscription plus configuration effort over three years versus build plus hosting over the same period.
- Why is error handling such a large share of the cost?
- Because in production, records fail for reasons your test data never produced: a field too long for the receiving system, a customer merged mid-sync, a vendor outage halfway through a batch. Handling those safely requires idempotency, retry logic, a place for failed records to land, and reconciliation to catch what slipped through. That work is the difference between an integration you can trust and one you have to babysit.
- What should we budget annually to keep an integration running?
- Plan on 15–25% of the build cost each year. That covers API version deprecations, credential rotation, schema changes on either end, and time spent investigating reconciliation mismatches. If a vendor tells you an integration needs no ongoing budget, they are describing something nobody is watching.
- Can we integrate a system that has no API?
- Usually yes, through file exchange, direct database access where the vendor permits it, or browser automation as a last resort. All three cost more to build and considerably more to run than an API-based connection. Treat them as a bridge with a defined end date rather than a permanent architecture, because a vendor UI change can take your operation down without warning.
- Should we integrate everything or replace the systems instead?
- Integrate when each system is genuinely good at its job and the only problem is that they do not talk. Replace when you are building integrations mainly to work around a system that no longer fits, since you will keep paying to connect something you are trying to escape. If more than two of your planned integrations exist to compensate for one platform, price the replacement before you build them.