Third-party API integration is the most consistently underestimated work in commercial software. The documentation reads clearly, the vendor publishes a client library, and someone says two weeks. Six weeks later the team is still arguing about what should happen when a webhook arrives twice for an order that was already refunded.

The gap is not incompetence. It is that the interesting part of an integration is never the request and the response. It is everything that happens when the other system behaves in a way its documentation never described, which it will, because it is a live product owned by people who have their own roadmap and no obligation to your release schedule.

The rule of thumb: A read-only integration that pulls data from one service usually takes one to three weeks. An integration that writes transactions takes three to six. A two-way synchronisation between systems that both allow edits takes six to twelve weeks and never truly finishes, because conflict resolution is a business problem wearing an engineering costume.

Why Integration Estimates Are Always Wrong

Estimates come from the happy path, and the happy path is perhaps a fifth of the work.

Writing the code that fetches a customer record, maps it to your model and saves it takes an afternoon. Then reality intrudes. The token expires mid-batch. The vendor returns a rate limit response with no warning that the limit was daily rather than per minute. A field the documentation describes as an integer arrives as a string for one legacy account. Pagination returns a record twice because another user edited it while you were reading. The sandbox environment accepts a payload that production rejects, because the sandbox was last updated in 2023.

None of these are exotic. They are the ordinary weather of integration work, and every one of them turns into a design decision that somebody has to make and test. Teams that have done this before build for them from the start. Teams that have not discover them one at a time, in production, usually on a Friday.

The Four Kinds of Integration, and Why They Cost Differently

Before estimating anything, establish which of these you are actually building. The difference between the first and the last is roughly an order of magnitude.

Read-only pull. You periodically fetch data from another system and store or display it. Failures are recoverable by retrying, and nothing downstream is corrupted if a run is missed. This is the cheapest and most predictable category by a wide margin.

Transactional write. You send something that changes state elsewhere: a payment, an order, a shipment booking, a support ticket. Now correctness matters, because a duplicate or lost request has a financial or contractual consequence. Idempotency, reconciliation and clear failure handling become mandatory rather than nice to have.

Event-driven consumption. The other system notifies you when something happens, usually through webhooks. This is efficient and removes polling delays, but it introduces an entire class of problems around delivery guarantees, ordering and verification that polling never had.

Bidirectional synchronisation. Both systems hold the same data and both allow it to be edited. This is the expensive one, and the cost is not technical. Somebody in the business has to decide what happens when a record is edited in both places within the same minute, and that conversation is usually longer than the implementation.

Where Integrations Actually Break

The failure modes repeat across every vendor and every industry. If your development partner cannot discuss these fluently, they have not built many integrations.

Authentication expiry. OAuth refresh tokens rotate, get revoked when a user changes their password, and quietly stop working when an administrator removes a permission. An integration that assumes credentials are permanent will run beautifully for four months and then fail overnight with no code change to blame. Store tokens centrally, refresh proactively rather than reactively, and alert on authentication failures as a distinct category from other errors.

Rate limits. Limits are frequently undocumented, applied per endpoint rather than globally, and stricter in production than in sandbox. Respect the retry headers when they are provided, back off exponentially with jitter when they are not, and never let a batch job hammer an endpoint at full speed because it happened to work during testing.

Pagination that shifts underneath you. Offset-based pagination over a dataset that other people are editing will duplicate and skip records. Cursor-based pagination usually will not. If the vendor offers both, use cursors, and if they do not, add reconciliation so you notice the gaps.

Partial failure. A request that times out has an unknown outcome: it may have succeeded, failed, or succeeded slowly. Retrying blindly creates duplicates, and not retrying loses transactions. The answer is an idempotency key generated by you and sent with every write, so the vendor can recognise a repeat, plus a reconciliation process that compares both systems on a schedule.

The Failures That Only Appear in Production

Webhooks that lie. Webhook delivery is at-least-once, not exactly-once, and ordering is not guaranteed. You will receive duplicates, you will receive events out of sequence, and occasionally you will receive an event for a record whose creation event has not yet arrived. Verify signatures on every payload, respond immediately and process asynchronously through a queue, deduplicate on the event identifier, and design handlers so that applying the same event twice does no harm.

Schema drift. Vendors add fields, extend enumerations and occasionally change behaviour without a version bump. Strict parsers break on unknown values; lenient parsers silently ignore data that mattered. Validate what you depend on, tolerate what you do not, and log unrecognised values so somebody finds out before a customer does.

Sandbox divergence. Test environments are usually simplified, often stale, and sometimes behave differently in exactly the areas that matter, such as timing, validation strictness and error codes. Budget for a controlled production trial with real credentials and small volumes, because that is where the last set of surprises lives.

Bidirectional Sync Deserves Its Own Warning

Two-way synchronisation looks like twice the work of one-way and is closer to five times, because it introduces questions that have no technically correct answer.

Suppose a customer’s address is updated in your application and in your client’s CRM within the same hour. Which one wins? Last write wins is easy to implement and quietly destroys data, particularly when clock skew between systems makes “last” ambiguous. Field-level merging preserves more but requires change tracking on both sides, which most vendor APIs do not expose. Manual conflict resolution is honest but needs an interface, a queue and somebody willing to look at it.

Deletion is worse. A record deleted in one system may need to be archived, anonymised or simply flagged in the other, and if you get it wrong in the direction that propagates, the mistake is unrecoverable. Most experienced teams refuse to synchronise deletions automatically at all, and that is usually the right call.

The practical advice is to avoid genuine bidirectional sync unless the business genuinely requires it. Designating one system as the authority for each field, and pushing changes in one direction only, removes almost all of the difficulty. When you are choosing between building a connector and adopting a platform that already has one, our build versus buy decision guide covers the commercial side of that trade-off.

What Third-Party API Integration Costs

Figures below assume UK agency rates and an application that already has a backend, background job processing and some form of monitoring. Add time if any of those are missing.

A straightforward read-only integration with a well-documented API typically runs from £4,000 to £12,000, covering the client, error handling, scheduling, mapping and tests. Transactional integrations that move money or create commitments usually land between £12,000 and £30,000, because idempotency, reconciliation and audit logging are all mandatory. Bidirectional synchronisation between two systems of record starts around £30,000 and rises quickly with the number of entities and the complexity of the conflict rules.

Then there is the part nobody quotes for. Every live integration needs maintenance, because the other side keeps changing. Budget ten to twenty per cent of the original build cost annually for version migrations, deprecation notices, credential rotations and the occasional emergency when a vendor ships a breaking change without adequate notice. An organisation running fifteen integrations has a standing maintenance commitment whether it has planned for one or not.

For the broader picture of how integration work fits into a wider delivery budget, our custom software development cost guide sets out the surrounding line items.

What a Well-Built Integration Looks Like

You can recognise a solid integration by what it does when things go wrong, so these are the details worth insisting on.

Every outbound write carries an idempotency key, so a retry cannot duplicate a transaction. Every inbound webhook is signature-verified, acknowledged immediately and processed from a queue, so a slow handler never causes the vendor to retry. Failed messages land in a dead letter queue where they can be inspected and replayed rather than disappearing into a log file.

Requests and responses are logged with correlation identifiers, so a support question about one order can be answered in minutes rather than by guesswork. Credentials live in a secret store with a documented rotation process, not in environment variables that nobody remembers setting. A circuit breaker stops calling a failing vendor after a threshold, protecting both your service and theirs from a retry storm.

Finally, there is a reconciliation job. It compares your records with theirs on a schedule and reports differences. It is unglamorous, it is the first thing dropped when a deadline slips, and it is the only reason anyone ever finds the thirty-one orders that silently failed last month.

Build Integrations That Survive the Vendor

Mecanik builds and maintains third-party API integration work as part of our custom software development services , covering payment providers, logistics carriers, CRM and ERP platforms, and the awkward internal systems that only have a SOAP endpoint and a phone number for support.

We build the queue, the idempotency layer, the reconciliation and the alerting as standard, because those are the components that decide whether an integration is an asset or a recurring incident. If your integration involves a language model rather than a conventional API, our guide to OpenAI API integration covers the differences, and if you need the API layer itself built on modern infrastructure, our walkthrough on serverless APIs with Cloudflare Workers shows the approach we favour.

Send us the vendor’s documentation and a description of what needs to happen, and we will give you a scoped estimate with the failure handling included rather than bolted on later.

Related reading: CRM and ERP Integration: Costs, Methods and Pitfalls , Custom API Development Cost: What You Pay For in 2026 , Software Licensing Models: An Enterprise Guide 2026 and REST API vs GraphQL in 2026 - How to Choose the Right One .

Frequently Asked Questions

How long does a third-party API integration take? A read-only integration typically takes one to three weeks, a transactional write integration three to six weeks, and a bidirectional synchronisation six to twelve weeks or more. The variation comes almost entirely from error handling and reconciliation rather than from the request-and-response code itself.

Why do webhook integrations fail silently? Webhook delivery is at-least-once and unordered, so duplicates and out-of-sequence events are normal. If your handler is slow or returns an error, the vendor retries, which can compound the problem. Acknowledge immediately, process from a queue, deduplicate on event identifier, and alert on failures explicitly.

What is an idempotency key and why does it matter? It is a unique value you generate and attach to a write request so the receiving system can recognise a repeat and avoid processing it twice. Without one, any timed-out request forces a choice between risking a duplicate transaction and risking a lost one.

How much should I budget for maintaining API integrations? Plan for ten to twenty per cent of the original build cost each year per integration. That covers API version migrations, deprecation deadlines, credential rotation and reactive work when a vendor changes behaviour without adequate notice.

Should I use a vendor’s official client library? Usually yes for authentication and request signing, since those are easy to get subtly wrong. Wrap it in your own interface rather than calling it throughout your codebase, so that retries, logging and a future provider change stay contained in one place.