Why you will not find a fixed price on this page
If you have landed on this page, you are probably hoping for a number: a price tag, a starting-from figure, a "small, medium, large" table you can put in front of the CFO. We understand that wish, and we deliberately do not play along. Not because we want to be vague, but because a fixed price on a general page is almost always misleading.
The reason is simple. Two integrations that are called the same on paper, such as "Shopify to Exact Online", can differ tenfold in budget. One is a straightforward order sync between two clean systems with clear data and a generous sandbox. The other has the same basic pairing, but nine years of legacy orders, a product catalogue that was never cleaned up, VAT rules that differ by country, its own discount structure, and a sales team that has been manually correcting order lines for years. The label is the same, but the project is entirely different.
What we can do, and what this page offers, is the insight you need to assess your own situation. The factors that really determine the price. The approaches you might consider. The hidden costs that rarely appear in quotes. And a way of working that gives you an honest estimate before a single line of code is written. For background on what an API integration actually is, see our guide to what an API integration is.
An API integration is not a product with a price tag. It is a project whose costs are determined by your systems, your data, your requirements and your organisation. This page helps you understand those costs before you request a quote.
The cost drivers behind an API integration
Every integration quote rests on the same set of factors. Some are fairly easy to estimate, others only become clear during the discovery phase. We go through them one by one, in the order that usually has the biggest impact.
Complexity of the endpoints
Not every endpoint is the same. A simple GET /customers is something very different from an endpoint where you have to post an order with line items, discounts, VAT rules per line, shipping method and payment status. The more mandatory fields and business logic involved, the more development hours are needed. With some vendors, write operations are considerably more complex than read operations; with others, it is the search API that becomes a minefield.
Authentication and authorisation
An API with a simple API key is something different from OAuth2 with refresh tokens and scopes. JWT flows with certificates, mutual TLS, SAP's Communication Users or NetSuite's Token-Based Authentication each require their own plumbing and testing. Enterprise authentication is often where inexperienced teams initially get stuck.
Retries, idempotency and error handling
An integration that only works on the happy path is a toy, not a production system. What happens when system B is briefly unavailable? When a rate limit is hit? When the same order is sent twice? Good integrations use exponential backoff, dead-letter queues and idempotency keys for every write operation. This is what separates working software from a daily source of incidents.
Data volume and frequency
A hundred orders a day is fundamentally different from a hundred thousand. At high volumes, APIs run into rate limits, and the choice between real-time and batch becomes more pressing. An honest estimate starts with a realistic picture of transaction volume, not just the average but also the peak on Black Friday or at month-end.
Real-time versus batch
Do you need real-time updates, or is an overnight batch enough? Real-time is more expensive: it requires an event-driven architecture, webhooks or a message queue, and monitoring that runs continuously. Many organisations combine the two: real-time for the critical flows, batch for master data.
Quality of the source and target systems
A modern SaaS API with good documentation is a joy to work with. A twenty-year-old on-prem application with an ODBC integration and no version control calls for some archaeology first. The same applies on the target side: the cleaner the schema, the less mapping work.
Master data management
Which system is the source of truth for which field? What do you do in case of conflicts? How do you handle duplicates? Customer numbers, product codes and ledger accounts often diverge. These agreements are not technical matters; they are governance. Organisations that only start this discussion once the build is underway end up paying for rework.
Monitoring, GDPR and ongoing management
Good monitoring means alerts on success rate, latency and queue depth, plus logging that gives enough context to diagnose faults quickly. Any integration that transfers personal data falls under the GDPR: processor agreements, EU data storage, no personal data in error logs, audit trails, and least-privilege access for integration accounts. For healthcare, NEN 7510 applies as well, and for finance, DORA. An integration is also not a disposable project: a healthy integration needs a maintenance layer that runs alongside it as a structural cost. We come back to that further on.
The four main approaches, and what they mean for cost
There are broadly four ways to set up an API integration, each with its own cost profile. The choice depends on your situation, not on fashion. We compare the two most common in detail in our guide API vs. integration platform; below is an overview of the whole field.
1. Point-to-point custom development
You build, or have built, a direct integration between two systems. Your own code, your own infrastructure, your own pace. Benefits: full control, no dependency on a platform vendor, and no recurring platform licence fees. Drawback: you carry the plumbing yourself: authentication, retries, mapping and monitoring. And if you have ten integrations, you have ten separate codebases to maintain. It suits organisations with a handful of deep, long-running integrations and in-house tech capacity.
2. iPaaS: Integration Platform as a Service
Platforms such as Workato, MuleSoft, Boomi, Make or n8n take much of the plumbing off your hands. Out-of-the-box connectors for hundreds of SaaS tools, visual flow builders, and built-in monitoring and retries. Benefits: speed, especially if you need to connect many SaaS tools the platform already supports. Drawback: recurring licence fees that grow with volume, platform lock-in that makes later migration more expensive, and for genuinely custom logic you often still end up with script steps that undermine the visual promise.
3. Embedded iPaaS
Tools such as Tray, Paragon or Prismatic are a variant of iPaaS aimed at SaaS builders who want to connect their own customers to their product. For multi-tenant scenarios, where a SaaS product has hundreds of customers who each want to connect their own tools, this can be an attractive route, as the connector maintenance sits with the vendor. The cost structure is usually per active customer or per executed flow, which fundamentally changes the unit economics of your product.
4. Custom middleware
An intermediate layer that you build, or have built, which connects multiple systems through a centralised architecture. Often based on a message bus (Kafka, RabbitMQ, Azure Service Bus), with a thin application layer that performs transformations. Suits larger organisations with multiple integrations and strict SLAs. Higher upfront investment, but the marginal cost of each new integration falls as the platform matures. Similar in approach to our broader work on smart API integrations.
The right choice is almost never one of these four in its pure form. Most organisations combine them: an iPaaS for the SaaS integrations that come with it anyway, custom for the deep pain points, and custom middleware once the number of integrations grows.
How to choose the right approach for you
There is no formula that spits out the right approach, but there are a number of questions that help frame the decision. Work through them for your own situation: it is free homework that pays off in later conversations.
How many integrations, now and in future?
One or two deep integrations rarely justify a platform with monthly licence fees. As the number grows, an iPaaS or an in-house middleware layer becomes increasingly attractive. The tipping point comes when plumbing work becomes a bigger cost than the business logic.
How deep should each integration go?
Broad, shallow integrations, such as fifteen fields between two SaaS tools, are the natural habitat of iPaaS. Deep integrations with complex business logic, validation and exceptions often get stuck in visual tools and are better served by code. For concrete examples of deep integration work, see our page on integrations within web development.
What operational capacity do you have in-house?
Custom-built integrations need someone to keep them running: reading monitoring data, handling alerts, tracking vendor changes. If you don't have that capacity, a platform with built-in tooling is often the wiser choice, otherwise you simply trade one-off build costs for recurring operational headaches.
How much lock-in is acceptable? And at what volumes?
iPaaS platforms make migrating to another solution complex, as flows are stored in their visual format. At high volumes the cost structure becomes decisive: licences that charge per action can come as a shock, whereas custom infrastructure benefits from economies of scale. Ask yourself: if this integration has to move to another platform in three years, what would that cost?
What is often NOT in the quote
One of the most unfair things about buying an API integration is that quotes often focus on the least important part: the initial build. What is frequently missing around it, and where the real money ends up going later:
Monitoring and alerting
The integration works on the day of go-live. Brilliant. But what if, next week, it quietly drops 10% of messages? Without monitoring, you only find out when a customer calls. Yet it isn't always explicitly in scope, so ask about it specifically.
Ongoing management
Vendors change their APIs, SaaS tools roll out new versions, schemas evolve. Without an agreement on ongoing maintenance, your build partner turns into a breakdown helper you hire at ad-hoc rates at the moment it has already broken.
Error handling for edge cases
The happy-path implementation is always quick to finish. The edge cases (a customer deleted mid-sync, an order line with an unknown field, timezones that don't line up) each need their own attention. Honest quotes are explicit about what is in scope.
Schema evolution and version control
Your product catalogue gets a new field. The accounting package splits a ledger account. Without an agreement on schema evolution, every change becomes a mini project.
Multi-tenant onboarding
Are you building a SaaS where each customer has its own integrations? Setup wizards, per-customer credential management and per-tenant monitoring are a workstream of their own, and they're often missing from initial quotes.
Versioning and documentation
A production integration that nobody can roll back is a time bomb. Feature flags, version pinning and blue-green deployments are your insurance. And the integration needs to be handover-ready: architecture documents, runbooks, comments in the code. Make sure this is part of the delivery, not a nice-to-have.
Ask every quote explicitly: how will this integration be monitored, who responds to outages, and what happens when the vendor changes their API? Answers along the lines of "you can always hire us" are answers in which no maintenance has actually been agreed.
An ROI framework that works without fixed prices
Justifying a quote becomes easier when you can set the costs against an honest estimate of the return. An API integration rarely delivers a single figure; it is a combination of effects, each of which can be quantified separately.
Time savings, measured honestly
How many hours per week do your staff currently spend on manual re-keying, producing exports, or correcting errors caused by manual work? Multiply by a blended hourly rate, annually. This is the most tangible part of the ROI and often the most underestimated, because people forget to count their own re-keying work.
Error reduction
How often each month does an incorrect invoice, an incorrect stock value, or a duplicate order go out? What does that cost in customer contact, correction work and reputation? During this exercise, organisations often discover that their "small" manual process is a major silent source of errors.
Customer satisfaction and NPS
Customers who see accurate stock on the webshop, receive correct invoices, and never hear "I'll have to check that in another system" are happier. In B2B this is directly measurable in NPS and retention; in B2C, in review scores.
Data quality as a strategic effect
An integrated systems landscape produces better reporting. CFOs steer on up-to-date figures, operations plan better, and marketing knows which products are genuinely selling. This is almost always the reason why organisations that succeed at it keep growing.
Opportunity cost of not integrating
Which growth are you missing right now? Which functionality can't you offer customers without the integration? Which market stays out of reach because manual processes don't scale? For growing organisations, this is often the heaviest cost item.
How to budget realistically
The order in which an API integration project is set up largely determines how well the budget holds up. We almost always recommend the same approach to organisations, regardless of size:
Step 1: Discovery, not build straight away
Start with a short discovery phase. The goal: map which systems are in place, which data flows between them, which business rules apply, which compliance requirements, which volumes, and who within your organisation owns what. This can be done in a few working sessions. A good discovery doesn't produce an integration, but it does produce the document that makes a fair quote possible.
Step 2: Scoping and estimation
On the basis of the discovery, a scope is drawn up: which integrations, which direction, which frequency, which requirements for monitoring and maintenance. Only then can a fair estimate be made, based on comparable projects the builder has delivered before, rather than a guess on a generic page. Expect a range, not a single figure: complexity often only surfaces during the build, and good builders are honest about that.
Step 3: Iterative build, not big bang
Start with one critical integration: the greatest pain point and the most tangible effect. Go live sprint by sprint, with direct feedback. Only once that is in place and stable, move on to the second and third. Big-bang projects, in which ten integrations are delivered at once, almost always end up delayed and over budget. Iterative is slower on paper, faster in practice.
Step 4: Maintenance as a structural cost
After go-live, budget for an ongoing maintenance component. Not because something is constantly breaking, but because vendors keep evolving their APIs, and so do your own systems. An organisation that treats maintenance as an ad hoc cost discovers after a year that its integrations have slowly degraded, and the repair is always more expensive than upkeep.
Set aside a buffer for the unexpected
Almost every integration project turns up something that wasn't visible during discovery. A field in the source system that is sometimes empty. A rate limit that only surfaces under peak load. A vendor update that lands right in the build period. A buffer of, say, 15% in time and budget isn't a luxury; it's realism. Projects without a buffer end in uncomfortable conversations; projects with one end with money to spare.
The costs after go-live: often underestimated
Quote discussions almost always focus on build costs. But an integration lives for years. What it costs after go-live is often greater over the long term than the initial investment. Three categories:
Reactive maintenance
Resolving incidents, handling alerts, carrying out ad hoc data corrections. How much depends on the robustness of the build and the stability of the connected systems.
Proactive maintenance
Updating API versions, handling deprecations, keeping dependencies up to date, and applying security patches. This work needs to happen even when everything is running smoothly; otherwise technical debt builds up.
Evolution and expansion
An integration rarely stands still. New fields, new flows, changed requirements. This evolution is positive, but it needs to be budgeted for.
Our rule of thumb: also budget for management after the build. The exact scope depends on complexity, volume and how much you can do in-house. During scoping, we give you an honest estimate that fits your specific situation. For the broader context of what determines the build costs of custom software, see our guide to custom software costs.
Frequently Asked Questions
Why don't you give a starting price?
Because a "from" price misleads in 9 out of 10 cases. We have built integrations that were finished in a few sprints, and integrations that dragged on for months, for things that looked identical from the outside. An honest figure requires a short scoping exercise. That scoping is free until the point at which we jointly decide to move forward.
Is iPaaS more or less expensive than custom?
It depends on your number of integrations, their depth, and your time horizon. For one deep integration you intend to use for ten years, custom is often cheaper over the lifetime. For twenty broad integrations with standard flows, an iPaaS is almost always faster and more cost-effective in the medium term. Our comparison API vs. integration platform goes deeper into this trade-off.
Wouldn't a no-code tool such as Zapier or Make be better?
For experiments, proofs of concept and internal integrations: fine. For production integrations involving customer data, financial flows or operational dependencies: not the first choice. No-code tools are brilliant for speed but less suited to the kind of robustness, monitoring and compliance that production demands. If business-critical work depends on it, choose something built for that purpose.
How much maintenance should I budget for?
Enough to handle vendor changes proactively and be available reactively when incidents occur. During scoping, we estimate this for your situation, based on the number of integrations, the volume, the stability of your connected systems and how much you can absorb internally. It is almost always more than you initially expect.
Does a cheap integration become more expensive over time?
Often, yes. Cheap quotes usually leave monitoring, error handling, retries, and maintenance out of scope. That gap doesn't cost you today, but it makes incidents harder to resolve without built-in tooling. We regularly see clients whose first supplier delivered something quickly and cheaply, and who are now paying to do it again, with the things that should have been there from the start.
How does a project with Appfront begin?
Start with a 30-minute introductory call, where we map out your situation, goals and constraints. This is followed by a short discovery phase, with no obligation, to get the scope clear. Only then do we provide an honest estimate, based on comparable work we have delivered before. No surprise hours, no hidden maintenance contracts.
What if my ERP or system supplier also offers an integration?
Sometimes that is the smartest route, especially if the standard integration covers 80% of your needs and the price is reasonable. Sometimes it is the most expensive option, because you pay for functionality you do not need or are tied to an upgrade path that does not suit you. We help with that trade-off without obligation; we have no vested interest in always building it ourselves.