How to Estimate Integration Work

Integration work means making two separate systems share data or trigger actions in each other. On the surface that sounds straightforward: system A sends customer details, system B receives them. In practice, the effort lives in the gaps between that simple description and a reliable, production-ready connection.

The first thing to understand is that integration estimates are fundamentally less predictable than estimates for standalone features. When you build a screen or a report inside your own application, you control the database, the code and the deployment environment. With an integration, a significant portion of the work depends on a third party: their documentation accuracy, their API stability, their rate limits, their test environments and their support responsiveness. No amount of careful planning eliminates that external uncertainty entirely.

A useful estimate therefore does not pretend to be exact. It separates what is knowable from what is not, and it builds in explicit risk allowances rather than padding every line item. The goal is to give a business owner or operations manager a honest range with clear conditions, not a single figure that unravels the moment the third-party system behaves unexpectedly.

The other distinction that matters is between the visible workflow and the invisible infrastructure. The visible part is the data mapping: which fields in system A correspond to which fields in system B, what transformations are needed, and what the business rules are. The invisible part covers authentication token refresh, error handling, retry logic, logging, monitoring and what happens when the remote system goes down or returns unexpected data. That invisible portion often accounts for half or more of the total effort, and it is the part most frequently omitted from initial estimates.

Integration patterns and what drives effort

Not all integrations carry the same complexity. Understanding which pattern you are dealing with is the starting point for any estimate.

One-way data push. Your system sends information to another system and does not wait for a structured response beyond an acknowledgement. An example is pushing completed order records to an accounts package. Effort is driven by the number of data fields, the complexity of transformation and the reliability of the receiving API.

One-way data pull. Your system requests data from a third party on a schedule or on demand. An example is fetching product prices from a supplier feed. Effort is driven by the volume of data, whether the API supports filtering and pagination, and how frequently the pull needs to happen.

Two-way synchronisation. Both systems can create and update records, and changes must be reflected in both directions without conflicts. An example is keeping a CRM and a customer portal aligned. This pattern is significantly more complex because you must handle race conditions, duplicate detection and conflict resolution.

Event-driven triggers. An action in one system causes an action in another, often in near real time. An example is creating a support ticket in your helpdesk when a certain type of error is logged in your application. Effort depends on whether the source system supports webhooks or whether your system must poll for changes.

Questions to answer before estimating

Before any meaningful estimate can be produced, the following points need answers. Missing answers do not mean the work cannot be estimated, but they do mean the estimate must carry wider uncertainty ranges.

• Documentation quality. Does the third party provide current, accurate API documentation? Poor documentation is the single largest cause of integration estimates overrunning.
• Test environment availability. Is there a sandbox or staging environment where your team can send test data without affecting live records? If not, testing becomes slower and riskier.
• Authentication method. What credentials or token exchange is required, and how frequently do tokens expire? Some methods are straightforward; others involve multi-step flows that add development and maintenance overhead.
• Data format and structure. Is the data provided in a consistent, well-structured format, or does it require significant parsing, cleaning or reformatting?
• Rate limits and throttling. Are there caps on how many requests can be made per minute, hour or day? If your volume exceeds those limits, the integration design must include batching, queuing or scheduling logic.
• Error responses. Does the API return meaningful error codes and messages, or does it fail silently or with generic errors that require investigation?
• Webhook support. If you need near-real-time data, does the third party offer webhooks, or must your system repeatedly poll for changes?
• Versioning policy. What happens when the third party releases a new API version? Is the old version deprecated with a clear timeline, or do changes happen without notice?

Typical business scenarios

Several integration scenarios come up repeatedly in UK business systems. A CRM connecting to an accounting package is one of the most common. The data mapping is usually clear—contacts, invoices, payment statuses—but the effort often lies in handling partial failures, reconciling discrepancies and dealing with the accounting system's stricter validation rules.

Customer portals that need to display data from a legacy back-office system present a different challenge. The legacy system may not have an API at all, requiring a middleware layer or direct database access, both of which carry their own risks and costs.

Internal tools that aggregate data from multiple SaaS products—such as pulling staff records from HR software, project data from a project management tool and financial data from an accounting platform—involve multiple integrations, each with its own authentication, rate limits and failure modes. The per-integration estimate may be moderate, but the combined testing, error handling and monitoring effort scales non-linearly.

Mistakes that distort estimates

Counting endpoints, not scenarios. A common shortcut is to look at the number of API endpoints involved and assign a fixed effort to each. This ignores the fact that one endpoint might involve a simple field-for-field copy while another requires complex business logic, conditional transformations and error recovery. Estimate by scenario and data flow, not by endpoint count.

Assuming the documentation is correct. API documentation frequently omits edge cases, describes behaviour that differs from the live system or fails to mention undocumented rate limits. Any estimate should include a dedicated investigation phase early in the project, before the bulk of development begins, to validate assumptions against the actual API.

Omitting error handling from the estimate. Building the happy path—where both systems are available, the data is clean and the response is as expected—is often a fraction of the total work. The remaining effort covers what happens when the remote system times out, returns a 500 error, rejects a record because of a validation rule not mentioned in the documentation, or responds with data in an unexpected format.

Forgetting ongoing maintenance. Integrations are not build-once-and-forget. The third-party system will change. Authentication methods will be updated. Fields will be added or deprecated. An estimate that only covers initial development without accounting for ongoing monitoring, incident response and periodic adjustment will understate the true cost of ownership.

Not planning for reprocessing. When an integration fails partway through a batch, you need a mechanism to identify which records succeeded, which failed and why, and then reprocess only the failures. Building that capability is a discrete piece of work that is easy to overlook.

Limitations of integration estimates

No estimate for integration work can be fully reliable until a developer has successfully authenticated against the real API, sent test data and inspected the actual responses. Anything before that point is an informed assessment, not a guarantee. A honest estimate will state this limitation explicitly and define what must happen to reduce the uncertainty range.

Estimates also cannot fully account for the third party's future behaviour. An API that is stable today may be deprecated, restructured or subjected to new rate limits next year. The estimate covers the work as understood at the time; it cannot insure against external changes outside your control.

Key checks before accepting an estimate

When a supplier presents an integration estimate, the following checks help assess whether it has been thought through properly.

• Does it distinguish between the investigation phase and the build phase, or does it present a single figure that assumes everything will work as documented?
• Does it explicitly mention error handling, retry logic and logging, or does it appear to cover only the happy path?
• Does it account for data transformation and mapping, or does it imply that the data structures already match?
• Does it reference rate limits and describe how the design will handle them?
• Does it include testing with realistic data volumes, or only with a handful of test records?
• Does it mention monitoring and alerting so that integration failures are noticed promptly?
• Does it identify which assumptions are uncertain and what the plan is if those assumptions prove wrong?

If an estimate arrives as a single number with no breakdown, no stated assumptions and no mention of error handling or testing, it has not been prepared with the rigour that integration work demands. The practical next step is to ask the supplier to restructure the estimate around the scenarios, the unknowns and the risk allowances described above. That conversation alone often reveals whether the team has genuine integration experience or is treating the work as a simple data-passing exercise.