There is no single honest price for a system or API integration without checking both sides of the connection. The cost depends on the available documentation, direction of data flow, number of business rules, quality of identifiers, failure handling, testing and the maintenance required after launch.
An integration does not end when one API request has been sent. It must also behave safely when data is incomplete, the same record arrives twice, one system is temporarily unavailable or a provider limits the number of requests.
When comparing costs, separate three areas:
- preparation and delivery, including process discovery, data mapping, development, testing and launch;
- third-party charges, if a provider charges for a plan, connector, platform or access to required functions;
- ongoing maintenance, including monitoring, incident handling and changes required when connected systems evolve.
The statement "we want to connect our store to an ERP" is therefore not enough for a responsible estimate.
If the integration forms part of a larger system, the article How much does a business web application cost? provides the wider context.
Why are the names of two systems not enough for an estimate?
The same pair of products can represent very different scopes. One company may only need new orders transferred once a day. Another may expect immediate two-way exchange of orders, stock levels, prices, payments and shipping statuses.
The first case may be covered by a straightforward import. The second requires decisions such as:
- which system owns the correct price and stock level;
- what happens if a customer changes an order during synchronisation;
- how the same product or customer is identified on both sides;
- how duplicate orders are prevented;
- which failures may be retried automatically and which require a person to decide;
- how the company verifies that both systems remain consistent.
The estimate depends on the complete flow, not only on the number of applications.
Four ways to connect systems
Not every integration needs a custom solution built from scratch. The first step is to check which route fits the process and the technical capabilities of both systems.
| Possible route | When it is worth checking | What may affect the cost |
|---|---|---|
| Ready-made connector | Both systems support a connector that covers the required scope | configuration, field mapping, plan or licence, testing and ongoing administration |
| File exchange | A system supports import and export but does not provide a suitable API | CSV or XML preparation, validation, scheduling, rejected-file handling and import control |
| API or webhooks | Data needs to move more frequently or with less delay | authentication, mapping, sending and receiving data, limits, retries, testing and monitoring |
| Custom intermediary module | Formats differ, several systems must be joined or company-specific rules are required | flow design, module development, infrastructure, logs, alerts, maintenance and further development |
The absence of an API does not always rule out automation. Files or supported import functions may provide a safe route. The solution still has to meet the required frequency, completeness and error-control needs.
What makes up the delivery cost?
Checking the capabilities of both systems
We first need to identify product versions, available modules, documentation, authentication methods and access to a test environment. Documentation may describe many functions, but some may not be available in the client's plan or installed version.
Describing the process and data direction
The scope must state what triggers the exchange, which data moves, in which direction and how quickly. It is equally important to decide which system is the source of truth when values differ.
Mapping and transforming data
Product names, addresses, tax rates and order statuses may be stored differently in each system. The integration must recognise those differences and transform data according to agreed rules.
Access and security
The connection should receive only the permissions it needs. Authentication, storage of keys, roles and the ability to revoke access are also part of the implementation scope.
Failure handling and retries
The design must cover missing required values, service outages, rate limits and repeated delivery of the same operation. A generic "an error occurred" message is not enough. The team needs to know what failed, whether it can be retried safely and who should respond.
Testing and launch
Testing covers more than the successful path. It should include invalid data, duplicates, partially completed operations and the unavailability of one system. The test scope grows when orders, settlements or data shared by several departments are involved.
Logs, alerts and ongoing support
After launch, it must be possible to understand what happened. Depending on the importance of the process, the solution may need logs, notifications, missing-data reports or a screen for controlled manual correction.
What changes an integration estimate the most?
Documentation and a test environment
Clear documentation and test access allow technical assumptions to be checked early. Missing documentation increases uncertainty. Contact with the provider or work on its side may also be required.
One-way or two-way exchange
Sending new store orders to an ERP is easier to define than full two-way synchronisation. A two-way flow requires conflict rules, a defined order of changes and a clear source of truth.
Number of data sets and rules
The number of fields is not the only factor. Formats, conditions, exceptions and dependencies also matter. One status may trigger several actions in the other system, while a simple-looking field may require a dictionary or additional verification.
Quality of identifiers and current data
If one product has different codes, customers appear more than once or stable identifiers are missing, matching and control rules must be agreed. Otherwise the integration may create duplicates or connect the wrong records.
Volume, frequency and provider limits
Moving a few records once a day is different from processing a large number of operations frequently. An API provider may also limit request volume or require a specific method for retrieving larger data sets.
Historical data and one-off migration
Launching the current flow does not automatically include all records from previous years. Historical import needs its own scope, data-quality checks and a decision on which information remains useful.
Exceptions that require a person to decide
Not every issue can be resolved automatically. If an employee must choose the correct record or decide how to handle an unusual order, the integration should provide clear information and a safe correction path.
Security and audit requirements
The scope grows when detailed operation history, separate permissions, stronger protection for sensitive data or an explanation of why a value changed is required.
Initial delivery is not the total integration cost
After launch, the integration becomes part of a business process. Before choosing an offer, check who will monitor it and what happens when either connected system changes.
Ongoing costs may include:
- charges for a plan, connector, platform or required feature;
- a server or other infrastructure for an intermediary module;
- monitoring, log retention and notifications;
- manual handling of cases that cannot be decided automatically;
- changes to keys, permissions or authentication methods;
- adaptation after an API, data format or business process changes;
- support and further development.
Not every integration needs a subscription or the same level of continuous support. The right arrangement must be confirmed for the particular process and written into the offer.
For a broader comparison of support models, read how much web application maintenance costs.
How should you compare two integration offers?
Two similar prices may cover very different work. One offer may include testing, failure handling and monitoring, while another covers only basic data transfer. Compare answers to the same questions.
| Comparison question | What should be described clearly |
|---|---|
| Which systems and versions are covered? | specific products, modules, environments and provider dependencies |
| In which direction does data move? | direction, frequency, trigger and acceptable delay |
| Which data is included? | records, fields, statuses, attachments, historical data and exclusions |
| Which system is the source of truth? | conflict and duplicate rules |
| What happens after a failure? | retries, notifications, queueing, manual correction and missing-data checks |
| How will the integration be tested? | test data, scenarios, acceptance criteria and responsibilities |
| What happens after launch? | monitoring, support, API changes, licences, infrastructure and maintenance scope |
| What is excluded? | migration, data cleansing, provider work, new rules and future development |
If these points are not written down, it is difficult to know whether two offers describe the same solution.
When can an estimate be prepared, and when is analysis needed?
A single, well-defined flow can be estimated after enough information has been collected and the technical options have been checked. At a minimum, we need the systems, direction, record scope, frequency, major exceptions and acceptance method.
A free qualification call with Domin Software may last up to 20 minutes. Its purpose is to identify the problem, goal and materials needed for the next assessment. It does not include free system diagnosis, integration design or a written report.
If the project covers several systems, two-way synchronisation, disorganised data or limitations that are difficult to verify, a better starting point may be business analysis and definition of the first stage. This is a paid stage with a separate estimate. If Domin Software later delivers the project resulting from that analysis, the amount already paid for the analysis is included in the total project cost.
What should you prepare before discussing an integration?
You do not need to write technical documentation yourself. Prepare information that helps us understand the flow and its unknowns:
- names and versions of the systems;
- links to documentation, if available;
- information about test accounts or environments provided by each vendor;
- a list of data that should move in each direction;
- an anonymised sample file or data structure without customer data, passwords or keys;
- frequency and approximate number of operations;
- the most important failure cases and exceptions;
- the method we will use to confirm the first stage works correctly.
You can start with the system integration planner. It helps you create a working map of the flow, but it does not produce an automatic estimate and does not replace checking the documentation.
For more detail on the flow itself, read How to plan an integration between two systems.
What do our earlier projects show?
In HUB.ITM, we processed data from different applications and formats and prepared it for import into Subiekt systems. This required precise mapping rules and control of data correctness.
HUB-2-API covered product import, eBay.de integration and an API used by three clients in France to check the offer and place orders. It shows how one project can include several flow directions, recipients and processes.
In a historical product-import system, we used CSV, XML, API and FTP to supply online stores. The exchange method depended on the source and target capabilities rather than on one tool being used in every case.
These projects are not a price list and do not determine the cost of a new project. They show why formats, rules and failure handling must be understood before an estimate is prepared.
Frequently asked questions
Can an integration be estimated from the names of the systems alone?
Usually not. The names allow initial research, but we also need the direction, data scope, frequency, rules, exceptions and failure-handling requirements.
Does an available API always mean a simple and inexpensive integration?
No. An API may expose only some required data, impose limits or require an additional plan. Documentation, test access and the specific operations must be checked.
Can systems be connected if one of them has no API?
Sometimes. File import and export, a supported connector or another documented route may be available. Feasibility and safety must be checked for the particular system.
Why does two-way synchronisation require more decisions?
The project must define which system takes priority, how conflicts are resolved and what happens when the same information changes on both sides. It also introduces additional failure and test scenarios.
Is historical data import part of an integration?
Only if it is included in the agreed scope. Moving historical data may require separate mapping, cleaning and verification.
Does an integration need maintenance after launch?
The level depends on the importance of the process and the connected systems. Monitoring, failure handling, responsibility for API changes and the process for ordering future changes should be agreed.
Can we receive an estimate without paying for analysis?
Yes, if the scope is sufficiently clear and the technical options can be checked without a separate stage. A short qualification call does not provide free diagnosis or solution design.
Can an integration be delivered in stages?
Yes. The project can begin with one important flow, clear acceptance criteria and later additions of more data or systems. Every stage should have a defined scope.
Choose the right next step
If you are still organising the requirements, begin with the system integration planner. It creates a working description of data direction, frequency, exceptions and the method used to check the result.
If you already know which systems and process need to be connected, see our system integration and API service. When the scope is larger or contains many unknowns, we can start with business analysis and definition of the first stage.
Sources
- OpenAPI Specification 3.2.1, accessed 28 October 2026.
- OAuth 2.0, RFC 6749, accessed 28 October 2026.
- OWASP API Security Top 10, accessed 28 October 2026.
- GitHub REST API rate limits, accessed 28 October 2026. GitHub documentation is an example of one provider's rules, not a rule for every API.