A programme manager at a distribution company in the Netherlands gets a brief from the board: by the end of the quarter, the new B2B ordering platform has to talk to the ERP, the CRM and the payment gateway. The platform vendor says “we have a ready API, so integration is a few weeks”. The internal IT team estimates the same work at six months. The ERP vendor says it will share documentation once a separate support contract is signed. And the board wants a single number at next Tuesday’s meeting.
Both sides of the argument are partly right. The platform vendor is telling the truth about its own API, but not about the APIs of the other systems, the data mapping, or what happens when a payment arrives and the order fails to appear in the ERP. The IT team knows these problems from experience, but cannot lay them out so that the board sees where six months comes from. What is needed is a method that turns “integration” into a list of concrete items, each with a number of person-days.
This article sets out that method. We break an API integration project down into interfaces, classify them by complexity, price a sample ERP, CRM and payments integration in person-days and euros, and then walk through the costs that are usually missing from the first proposal: API rate limits, middleware licences, contract testing, payment provider fees and maintenance. At the end you will find a list of questions to put to an integration vendor.
Why is “it’s just hooking up the API” the most expensive sentence in the project?
Because it describes roughly a fifth of the work. Calling an API that returns data is the easiest part of an integration, and it really can be done in a few days. The rest of the work is answering questions that sentence never asks. Which CRM field maps to which ERP field, and what happens when a customer has three delivery addresses in one system and one in the other? What happens when the ERP is unavailable for two hours every night during backups? How do you avoid a duplicate order when the payment gateway sends the same notification twice? Who finds out, and how, that 40 orders have been stuck between systems since yesterday?
The scale of the problem is well documented. MuleSoft’s 2025 Connectivity Benchmark, based on a survey of 1,050 IT leaders worldwide, found that the average enterprise manages 897 applications, of which only 29% are integrated. The European results, drawn from 400 IT leaders in the UK, France, Germany and the Netherlands, put the average at 789 applications with only 32% connected. Respondents also reported that around 39% of IT team time goes to designing, building and testing custom integrations. Integration is not a side task of a project; it is one of its main cost lines.
The second reason the sentence is expensive: it pushes risk to the point where it costs the most. If the estimate assumes integration is “hooking up the API”, problems with data mapping, missing fields in an API and an unavailable test environment surface during acceptance testing, when the schedule is already tight and the team is billed by the day. The same problem found during analysis costs a fraction.
The takeaway for a programme manager: do not ask a vendor what “the integration” costs. Ask what each interface costs and exactly what it includes. The basic concepts are set out in our glossary entry on systems integration.
What goes into an integration estimate?
The basic unit of an estimate is an interface: one data flow between two systems for a defined purpose, such as “orders from the platform to the ERP”, “stock levels from the ERP to the platform” or “payment confirmations from the gateway to the ERP”. An interface has a direction, a frequency, a data format and an owner on each side. Pricing “the ERP integration” without breaking it into interfaces is like pricing “the flat renovation” without a list of rooms.
Each interface involves six kinds of work:
- Analysis and data mapping. Deciding which fields correspond, what the code lists are (statuses, units, currencies, VAT rates) and what to do with records that do not fit. This is analyst work with business experts from both sides.
- Build. API calls, transformations, writes, authentication. The part everyone sees.
- Error handling and resilience. Retries, queues for when a system is down, idempotency (so that a repeated message does not create a second order), compensation when one step succeeds and another fails.
- Testing. Unit tests of transformations, integration tests on both sides’ test environments, contract tests, end-to-end tests of the whole business process.
- Monitoring and operations. Logging, alerts, a view of stuck messages, a manual repair procedure.
- Coordination. Communicating with the vendors of the other systems, getting access, agreeing deployment windows.
On top of that sits a layer shared by all interfaces: how data is exchanged (direct calls, a message queue, an integration platform), the logging and monitoring standard, and how secrets and access are managed. It is built once and its cost is spread across all interfaces. For an overview of the patterns in this layer, see our article on software integration patterns and approaches.
How do you classify interfaces by complexity?
There is no public standard for interface effort, so the ranges below are our estimating assumption, not market data. They are for a first approximation and for checking whether a vendor’s proposal is even in the right order of magnitude. Each range covers all six kinds of work from the previous section, not just coding.
Simple interface: 10-20 person-days. One-way, periodic (every 15 minutes or once a day), documented REST APIs with test environments on both sides, a dozen or two fields, simple code lists. Example: exporting the price list from the ERP to the sales platform.
Medium interface: 20-45 person-days. Two-way or event-driven (webhooks), with statuses that change over time, several code lists to map, error handling and retries, and a requirement that a repeated message must not trigger a duplicate operation. Example: orders from the platform to the ERP and fulfilment statuses back.
Complex interface: 45-90 person-days or more. The other system has no proper API, so the integration runs through files, poorly documented SOAP, database views or an intermediate layer; or the process requires reconciliation between systems, multi-step transactions with compensation, migration of history or processing of large volumes. Example: two-way synchronisation of customer master data between a CRM and an older ERP in which one customer can have several accounts.
Two things move an interface between classes more than the technology does: the quality of documentation and availability of a test environment on the other side, and how fast the other system’s vendor responds. An interface that is technically simple becomes medium when every question to the ERP vendor waits a week for an answer. So when classifying, ask not only “what is the API like?” but also “who on the other side answers questions, and how quickly?”
The classification gives a programme manager a quick budget check before the first proposal arrives. Count the interfaces in each class, multiply by the person-day range, add 10-20% for the shared layer and multiply by the day rate. A programme with four simple, three medium and one complex interface comes to 4 × 10-20 + 3 × 20-45 + 1 × 45-90, or 145-305 person-days, plus the shared layer. If a vendor’s proposal is a third of that, it does not mean the vendor is efficient. It means something was not priced, and you need to ask what. If it is three times higher, ask which interfaces the vendor classed as complex and why. Sometimes they are right, because they know the other system better than you do.
Which factors push the price of an integration up the most?
The table below lists the price factors worth going through with a vendor before it estimates. For each one it shows what the cheap and expensive situations look like, and the question that tells you which one you are in.
| Factor | Cheaper case | More expensive case | Question to ask before the estimate |
|---|---|---|---|
| Quality of the other side’s API | REST with an OpenAPI description, sandbox, examples | No API, files, undocumented SOAP, database views | Is there an API specification and a working test environment? |
| Direction and mode of flow | One-way, batch, once a day | Two-way, event-driven, near real time | How fast must data reach the other side, and which system is the source of truth? |
| Data mapping | Shared code lists, a dozen fields | Different data models, many code lists, calculated fields | Is there a field and code-list mapping signed off by the business? |
| Error handling | Retry and alert are enough | Idempotency, compensation, reconciliation | What should happen when one step of the process succeeds and another fails? |
| Volume and API limits | A few hundred operations a day | Hundreds of thousands of operations, rate limits, need for batch operations | What is the daily volume, and what limits does our SaaS plan have? |
| Security and compliance | API key, no special data protection | OAuth with rotation, personal data, payment data, audit | What data flows through the interface, and who is responsible for protecting it? |
| Test environments | Full test environments on both sides | No sandbox, testing on a production copy or in production | Where will we test, and who prepares test data? |
| Availability of the other vendor | Answers within a day, shared channel | Questions through support tickets, paid consulting hours | Who on the other side answers technical questions, and what does it cost? |
| Integration layer | Direct calls between two systems | Licensed integration platform, many systems, queues | Do we need middleware, and who pays for its licence? |
The table yields a practical rule: most price factors sit outside the code. They concern documentation, environments, people on the other side and business decisions about data. That is good news for a programme manager, because these factors can be identified and partly removed before the start, before a development team begins billing time.
What does a sample ERP, CRM and payments integration estimate look like?
Back to the company from the introduction. The B2B ordering platform (already connected to the CRM) has to exchange data with the ERP and the payment gateway. Invoices are issued by the ERP; the integration has to pass the invoice number and status to the platform so customers can see them in their account.
Assumptions: senior rates from our pricing page, EUR 335-485 per day fully loaded; complexity classes as in the previous section; the ERP has a documented, if incomplete, API and a test environment.
Person-day breakdown (lower and upper bound):
- A. Orders from the platform to the ERP and fulfilment statuses back (medium interface): 30-45 person-days
- B. Prices and stock levels from the ERP to the platform (simple, close to medium because of customer-specific prices): 15-25 person-days
- C. Payments: gateway, webhook notifications, refunds, reconciliation with the ERP (medium): 20-35 person-days
- D. Invoice number and status from the ERP to the platform (simple): 10-15 person-days
- E. Shared layer: queue, logging, monitoring, alerts, retries: 15-25 person-days
- Development subtotal: 90-145 person-days
- F. Contract, integration and end-to-end testing, test data: 20-30 person-days
- G. Data mapping analysis and coordination with system vendors: 15-25 person-days
- Total: 125-200 person-days
The arithmetic:
- Lower bound: 125 × EUR 335 = EUR 41,875
- Upper bound: 200 × EUR 485 = EUR 97,000
- With 20% contingency: EUR 50,250-116,400
The contingency is higher than the 15% we usually apply to application builds, because in integration work a larger share of the risk sits with systems you do not control: incomplete APIs, version changes during the project and the availability of people on the other side.
Translated into a team, 125-200 person-days is about 7-11 person-months at 18 billable days per month, for example three people for 2.5-4 months. That lets you test the deadline straight away: if the board expects go-live in six weeks, you need either a larger team (which does not shorten the timeline proportionally, because coordination with vendors has its own pace) or a narrower first stage.
The most common way to shorten the first stage: go live with interfaces A and C, orders and payments, first, and import prices and stock in a nightly batch for a transition period. Invoice statuses can wait for stage two, because customers still receive invoices through the usual channel.
What do API rate limits cost, and why must you calculate them before you start?
API rate limits are the most overlooked cost of integrating with SaaS systems, because they do not appear in the integration vendor’s proposal but in the SaaS vendor’s price list. Almost every SaaS system limits the number of API calls over time, and the limit depends on the plan you buy.
A good, publicly documented example is HubSpot. According to HubSpot’s developer documentation, a privately distributed app on the Free and Starter tiers can make 100 calls per 10 seconds and 250,000 calls per day per account; on Professional, 190 per 10 seconds and 625,000 per day; on Enterprise, 190 per 10 seconds and 1,000,000 per day. A paid add-on raises the limits further. Other systems have other numbers, but the mechanism is the same.
Why does this matter for the estimate? Do the maths. An initial sync of 200,000 customer records at 100 calls per 10 seconds, one record per call, takes 20,000 seconds, or about 5.5 hours of continuous work, assuming no other integration uses the same limit meanwhile. If daily volume approaches the daily cap, you have three options and each costs money: a higher SaaS plan, a paid add-on for higher limits, or extra developer work on batch operations, caching and incremental sync.
What to do before the estimate: for each SaaS system in the project, write down the API limits for your plan from the documentation, estimate daily operation volume (with headroom for growth) and check whether the API offers batch operations. If volume exceeds half the limit, treat it as a risk and budget for a higher plan or extra person-days.
Interface architecture also affects limit consumption. An integration that polls a system every minute asking “has anything changed?” uses up the limit even when nothing happens: 1,440 calls a day per object type before it processes a single record. An integration based on notifications (webhooks), where the source system reports changes itself, uses calls only when there is something to process. Building webhook handling costs more up front, because it needs a publicly reachable endpoint, signature verification and handling of repeats, but at high volume it pays back in limits and latency. Make that decision deliberately during analysis rather than leaving it to a developer mid-build.
When does middleware or iPaaS pay off, and how should you cost it?
With two systems, a direct connection is usually enough. With five systems exchanging data in different combinations, direct connections turn into a web in which every change to one system means fixes in several places. That is when an intermediate layer is worth considering: an integration bus, a message queue or an integration platform as a service (iPaaS).
An intermediate layer costs money in two places. The first is the licence or subscription. Integration platforms use different pricing models: by number of connections, by number of environments, by message volume, by compute capacity. Prices are rarely public and price lists change, so we do not quote figures here. Ask each platform vendor for a quote for your volume, number of environments (production, test, development) and expected growth over three years. Ask directly about overage costs and the minimum contract term.
The second cost is skills. An integration platform needs people who know it. If, after go-live, nobody in the company can change a flow in the platform, every change becomes a job for an outside specialist.
When an intermediate layer pays off: when you integrate more than three or four systems, when you plan to replace one of them within a few years (the layer isolates the other systems from the change), when you need central monitoring of all flows, or when the same flow serves several consumers. When it does not: with two or three systems in a stable landscape. Then a simple queue and good logging are enough. If you expose your own APIs externally, also consider an API gateway; its role is explained in our glossary entry on the API gateway.
Why are contract testing and test environments a separate budget line?
Integrations rarely break on go-live day. They break a few months later, when one side changes its API: adds a required field, changes a date format, removes a value from a code list. If nobody catches it before deployment, the first signal is customer complaints or discrepancies in accounting.
Contract testing protects against this. Each side of an integration records its expectations of the other (which fields, in what format, with what values) as a contract, and automated tests check on every code change that the contract still holds. The method is explained in our glossary entry on contract testing, and practical implementation in a microservices architecture is covered in our article on contract testing and API compatibility.
Contract testing costs money because it needs three things: agreeing contracts with the other side, writing the tests and wiring them into the continuous integration pipeline. With external systems whose code you cannot influence, part of the contract is verified by tests against their test environment rather than on both sides. In our example, testing of all kinds is 20-30 person-days, about 15-16% of the whole project. If a proposal contains no testing, or only “acceptance testing on the client side”, the difference does not disappear. It moves to your team and to production.
Test environments on the other side are a separate cost. Some ERP and industry-system vendors offer a sandbox only in higher support tiers or for an extra fee. No test environment means testing on a copy of production or, at worst, in production, which raises both risk and effort. Ask every vendor on the other side whether a test environment is included in your contract, and budget for it if it is not.
Which payment and regulatory costs need to be added?
A payment gateway integration has a one-off cost (building the interface) and a running cost that is not in the integration vendor’s proposal: transaction fees. Stripe in Ireland, for example, lists on its pricing page 1.5% + €0.25 for standard EEA cards, 2.5% + €0.25 for UK cards and 3.15% + €0.25 for international cards, plus 2% where currency conversion is needed. Other providers have other price lists and negotiate terms at higher volumes. On a €2,000 B2B order, 1.5% + €0.25 is €30.25, so a thousand such orders a month cost €30,250 a month in fees. That number belongs in the business case, not on the first provider invoice.
Payment integration also has requirements that raise effort: handling notifications that may arrive several times or out of order, partial refunds, failed payments and reconciling receipts with accounting. That is why the payment interface in our example is medium, not simple, even though payment providers’ APIs are usually very well documented.
The second regulatory cost is e-invoicing. National e-invoicing mandates change how invoices flow between systems, and any process that uses invoices (customer portal, collections, payment reconciliation) may then need the invoice’s official identifier and status. Poland is a concrete example: according to the Polish Ministry of Finance, issuing invoices through the National e-Invoicing System (KSeF) has been mandatory since 1 February 2026 for businesses whose 2024 sales exceeded PLN 200 million, and since 1 April 2026 for other businesses, with transitional exceptions until the end of 2026. If you operate a Polish entity, or your ERP vendor is adapting to a mandate in another country, check whether the ERP exposes the new data through its API. If it does not, that is an extra interface in the project.
Fixed price or time and materials: how should an integration project be billed?
Integration projects have an unusual risk profile: much of the uncertainty sits with systems and people that neither you nor the integration vendor controls. That shapes the choice of billing model.
Fixed price makes sense for an interface with a documented API, a working test environment, an agreed data mapping and a named contact on the other side. The vendor can then estimate the work reliably and you get predictability. For interfaces with unknowns, a fixed price will either carry a large contingency or lead to disputes about whether “the ERP vendor’s broken API” is in scope.
Time and materials makes sense for complex and uncertain interfaces. You keep control through a budget per interface, a weekly progress report and a clear completion criterion.
The model that usually works best for integration projects is staging. Stage one is a fixed-price analysis: an inventory of interfaces, a check of APIs and environments on each side, data mapping and complexity classification. Its output is a list of interfaces with estimates. Simple and medium interfaces with complete analysis can then be priced as fixed price, and complex ones as time and materials with a budget cap. We described how risk is shared under fixed price in our article on who really pays for risk transfer in fixed-price software.
What should you ask an integration vendor before signing?
A list of questions that lets you compare proposals and catch assumptions a vendor left unsaid:
- How many interfaces did you break the project into, and how many person-days did you assign to each? Without a breakdown you cannot compare proposals or price changes.
- What exactly does each interface cover? Direction, frequency, mapping, error handling, idempotency, monitoring.
- What did you assume about APIs and environments on the other side? If the proposal assumes a sandbox that does not exist, the estimate is out of date.
- How do you test, and is contract testing in scope? Who prepares test data, and on which environments does testing take place?
- What do monitoring and error handling look like after go-live? Who receives alerts, how fast they respond, how stuck messages are repaired.
- Which costs on the side of system vendors and licences do you expect? SaaS plans because of API limits, middleware licences, paid test environments, ERP vendor consulting hours.
- Who owns the integration code and the integration platform configuration? Repository access and flow documentation.
- What happens when the vendor of a system on the other side changes its API? Who detects it, who fixes it, and on what billing basis.
Warning signs: a single figure for “the ERP integration” with no breakdown, no mention of error handling and monitoring, testing “on the client side”, an unverified assumption that every system has a ready API, and no line item for data mapping analysis. None of these necessarily means bad faith, but each means a cost that will appear later. If an integration project is already running and those costs are appearing now, review what has been built before ordering the next stage.
How much does it cost to maintain an integration after go-live?
An integration is not finished on go-live day. Systems on both sides change, SaaS vendors release new API versions and retire old ones, regulations change (rates, document formats), and the business adds new fields and statuses. Each such change requires a review of mappings, testing and sometimes a rebuild of part of an interface.
No public source measures the cost of maintaining integrations, so here is a budgeting assumption: 10-20% of build cost per year. For the example in this article (EUR 41,875-97,000) that is about EUR 4,200-19,400 a year. The lower end applies to a stable landscape where most systems are mature ERPs with infrequent API changes. The upper end applies to integrations with many SaaS systems that release new API versions often.
That cost covers monitoring and responding to alerts, manually repairing stuck messages, updates after API version changes, library and security updates, and small mapping changes requested by the business. On top come running costs independent of labour: integration platform subscriptions, higher SaaS plans because of limits, and payment fees.
The best way to cut maintenance cost is build quality: contract tests that catch changes before production, monitoring that shows a problem before a customer reports it, and flow documentation that lets someone who did not build the integration make a change.
How do you get started: from an interface map to a reliable estimate?
Before you invite vendors to bid, prepare three things. First, an interface map: a list of data flows with the direction, frequency and business purpose of each. Second, for each system, information about its API: whether it exists, which standard it follows, whether there is documentation and a test environment, what the limits are on your plan and who on the other side answers questions. Third, volumes: how many orders, payments and customer records per day, today and in three years.
With that material, vendors will price the same thing, and you will compare proposals interface by interface rather than by one total. Estimation methods for IT projects in general are covered in our glossary entry on IT project valuation and estimation.
If you want to go through this process with us, the software development team at ARDURA Consulting builds systems integrations through APIs and middleware. We start with an analysis that ends in an interface map with complexity classes, a list of risks on the side of external systems and an estimate in person-days at published rates. Integration and contract testing can be taken on by our software testing team. For the broader picture of how we approach connecting systems into a coherent architecture, read our article on IT systems integration.