Every order that someone retypes from the online store into the accounting package costs a few minutes and carries the chance of a typo. At 100 orders a week, that adds up to days of work per year, and the errors only surface when a customer or the accountant spots them.
An API integration is a connection between two software systems that exchange data automatically through an API (application programming interface). One system asks a question or sends a message, the other answers or processes it, and nobody retypes anything. Orders, customer records, and stock levels stay identical across online store, ERP, and accounting system.
Below we explain how an API integration works, which examples you see in practice, what drives the cost, and when to have one built. We've built software and integrations for healthcare, education, manufacturing, government, and energy for more than 30 years, and the examples come from that work.
How an API integration works
An API is the official entrance of a software package for other software. Where a user logs in through a screen, another system knocks on the API: a fixed set of addresses (endpoints) where you can retrieve, create, or change data. The vendor's documentation lists which requests you can make and the answer format, usually JSON. Wikipedia explains the term API in more detail.
The integration is the software that uses that entrance. Every five minutes, for example, it collects new orders from the online store, translates the fields into the ERP's format, and passes them on. The API is an interpreter with a fixed vocabulary. The integration is the conversation you have with that interpreter, including what happens when the other party doesn't pick up.
Three ways to connect systems
- REST API. The most common form. Your system requests or sends data over HTTP, the same technology a web browser uses. Almost every modern package offers one, from the Dutch accounting packages Exact Online and AFAS to HubSpot and Salesforce.
- Webhooks. Here the direction flips. The source system itself reports that something happened, for example that order 4531 has been paid. Your integration no longer has to ask every minute for news.
- File exchange. A CSV or XML export placed on an SFTP server at fixed times and read in on the other side. Old-fashioned, and sometimes the only option for software without an API. Fine for nightly batches, too slow for stock levels that must be right immediately.
In practice you combine these forms. A webhook announces a new order, a REST call fetches the details, and a nightly export checks that everything matches. Once more than two or three systems talk to each other, the number of integrations grows fast and an intermediate layer comes into view. Our article on middleware covers that.
Our software integration page describes how we handle integrations with ERP, CRM, and legacy systems, from first inventory to ongoing maintenance.
Examples of API integrations in practice
Most integrations solve the same problem: the same data lives in two systems and someone keeps them in sync by hand. Four situations we come across often:
- Online store to Exact Online. Orders, customers, and payments flow automatically into the accounting system, and stock levels flow back the other way.
- CRM to ERP. A won quote in the CRM becomes an order in the ERP, with the same customer code and prices.
- Scheduling to HR. Hours and shifts from the scheduling tool go to the payroll package. Payroll no longer copies rosters and only handles the exceptions.
- RFID to ERP. In manufacturing, companies connect scanners and RFID readers to their product catalog and ERP, so every scanned pallet is in the system right away. We built an integration like this for Deron.
Joris heads the order desk at a technical wholesaler with 35 employees. His team retypes about 60 online orders into the ERP every day, and each month the bookkeeper spends a day hunting for differences between store and ledger. A REST integration between store and ERP puts every order into the system within a minute, with the right customer code and pricing agreement. The order desk only handles the exceptions: orders without a valid VAT number or with a delivery address outside the EU, in a separate list ready for review.
Our case about RFID linked to the product catalog and ERP at Deron walks through how such an integration comes together in manufacturing. If you'd rather start with your own situation, a no-obligation advisory call is the place.
What determines the cost of an API integration
Naming a figure without knowing the systems would be a guess. We can show where the hours go. Five factors determine most of the budget:
- Number of systems and directions. One system reading from another is manageable. Two systems updating each other in both directions need rules about who wins when both change the same record.
- Quality of the API and its documentation. A modern, well-documented REST API saves days of work compared to an outdated interface with missing or inaccurate documentation.
- Data volume and speed. 100 orders a day is something different from 10,000 stock movements an hour. The volume decides whether a simple script is enough or you need queues and monitoring.
- Error handling. Decide in advance what happens when the ERP is offline for 10 minutes, a customer appears twice in the CRM, or a required field stays empty. Most of the build time goes into these exceptions. The standard path is usually built quickly.
- Maintenance after delivery. Vendors change their APIs, certificates expire, and volumes grow. Budget for monitoring and periodic maintenance on top of the build.
An integration between two modern packages with limited volume is often a matter of days. An integration between an online store, an ERP, and an outdated warehouse system with tens of thousands of movements a day takes weeks to months. Both are API integrations. The difference lies in the exceptions you cover.
Building a custom API integration or choosing a standard connector
Many packages ship with ready-made connectors to popular software, for example between an e-commerce platform and an accounting package. Such a connector is enough when your process is standard and the vendor's choice of fields and frequency suits you.
Having a custom API integration built becomes interesting in three situations:
- Your process differs from the standard: your own article codes, volume pricing per customer, or approval steps the connector doesn't know about.
- One of the systems is custom-built or an older package with no connector.
- You want to own the logic, so a third party's roadmap doesn't dictate your process.
Marieke is an HR advisor at a healthcare organization with 600 employees. The scheduling tool has a standard connector to the payroll package, and it works well for regular shifts. Irregular-hours allowances and sleep-in shifts come through wrong, so payroll corrects dozens of lines by hand every month. A custom integration that applies the collective labor agreement rules before the hours reach payroll removes those corrections. The connector stays in use for everything else.
We build integrations like these as part of custom software development and as standalone projects, with a team of 30+ engineers in Nijmegen and Sarajevo. The same people who build the integration keep it running, which matters for software that processes orders or payroll lines every day.
Risks to cover up front
An integration that works today can stall next year because of a change on the other side. Five points to arrange in advance:
- Missing or outdated documentation. Request the API documentation before you accept a quote and test a few calls in a sandbox. Gaps between the documentation and reality then surface before they cost money.
- Rate limits. Vendors cap the number of calls per minute or day. Plan the frequency based on how current the data needs to be.
- Version management. APIs change. A vendor announces a new version and switches the old one off a year later. Without an owner who reads those announcements, the integration stops on a random Tuesday. Record who maintains the integration and who follows the vendor's release notes.
- Older systems without an API. With older packages, direct database access or file exchange is often all that's left. That can work, with extra attention to security and continuity. The Dutch National Cyber Security Centre (NCSC) describes the risks of legacy systems clearly.
- Security. Every integration is an extra door to your data. Use a separate API key per integration, with minimal permissions, and log who retrieves what and when. We're ISO 9001 and ISO 27001 certified and take those requirements as the starting point for every integration we build.
Frequently asked questions
What does an API integration cost?
That depends on the number of systems, the quality of the API documentation, the data volume, and the error handling and maintenance requirements. An integration between two modern packages with limited volume is usually a small project. An integration with an old system without documentation calls for a thorough inventory first. After an exploratory conversation we give a concrete estimate with clear assumptions.
What is the difference between an API and an API integration?
An API is the entrance a software package offers to other software: the agreements about which data you can retrieve and in which format. An API integration is the software that uses that entrance so two systems actually exchange data. The API is usually already there. The integration is what you have built.
Where can I get an API integration built?
From the vendor of one of the packages, from an integration platform, or from a software company that builds the integration and maintains it. Pay close attention to who maintains the integration after delivery and who owns the code. Our approach is on the API development page.
How long does it take to build an API integration?
A simple integration between two well-documented systems is often ready within a few weeks, including testing. Integrations with multiple systems, high volumes, or an outdated package run to several months. The inventory up front determines the lead time more than the programming itself.
Key points and next step
An API integration lets systems exchange data automatically, so nobody retypes anything. Keep these points in mind:
- The API is the entrance of a package. The integration is the software that uses it.
- REST, webhooks, and file exchange each have their place and are often combined.
- The cost depends on the number of systems, the documentation, the volume, the error handling, and the maintenance.
- A standard connector is enough for a standard process. Have an integration built as soon as your process differs or a system has no connector.
- Record in advance who maintains the integration and who follows the vendor's changes.
The next step is an inventory: which systems, which data, how often, and what happens when something fails. With more than 30 years of experience and 100+ projects, we're happy to take a look with you. Book a no-obligation call and we'll tell you honestly whether a connector is enough or a custom integration pays off.
