APIs & system integration
API development & system integration
When your systems know nothing about each other, your team carries the data across by hand. Through careful API development we connect ERP, CRM, online shop and line-of-business systems so data moves reliably – specified in OpenAPI, versioned and with failure handling. At the end, the code, credentials and documentation belong entirely to you.
Perspective
When API development is worth it
An integration is the right answer when the same data is needed in several places – and currently gets there by hand.
System integration pays off as soon as your work spans several systems: orders start in the online shop, are invoiced in the ERP and followed up in the CRM. While each system works on its own, your team is the connection – via exports, copy and paste or a shared inbox. An integration takes that over for good, by fixed rules rather than by whoever is on shift. The same applies if you want to open your data to partners, customers or an app.
The warning signs are quiet but expensive: customer records differ between CRM and ERP, stock levels are only correct after the overnight import, and nobody is quite sure which version is current. Often there already is a connection – a script a former colleague wrote, which fails silently every now and then and which nobody dares to touch. Errors then surface only when a customer calls.
Honesty applies here too: if your systems already ship with a maintained standard connector, or an established integration platform covers your case, that is usually cheaper than a bespoke build – and we will tell you so. If data only needs reconciling once a quarter, a well-documented export is often enough. Custom API development pays off where the standard cannot represent your data logic, or where the connection is business-critical.
Services
What we actually build
From a single ERP integration to API development for your partners – always with a specification, tests and documentation.
REST APIs to an OpenAPI spec
We design the interface as an OpenAPI specification first and build it second. Everyone involved knows up front which data moves where, and your team or your partners can develop in parallel against the same contract.
ERP and CRM integration
We connect ERP, CRM and line-of-business systems through the interfaces they already offer – or, where there is none, through database access or file exchange. Along the way we settle which system is the source of truth for which data.
Webhooks and events
Instead of polling for changes every hour, the integration reacts to events: a new order, an updated contact or an incoming payment triggers the next step – with a queue in case the other side is unavailable.
Syncing data between systems
Scheduled or continuous reconciliation of master data, stock and status, with fixed rules for conflicts. Every run is logged, so you can trace what was written to which system, and when.
Retry and failure handling
The other side is not always reachable. We build retries with increasing back-off, detect duplicate messages and report persistent failures instead of quietly dropping them. Metrics, logs and alerts are there from day one.
Versioned interface contracts
When an interface has to change, the old and new versions run side by side for a while. Around that come authentication via OAuth 2.0, narrowly scoped permissions per application, and documentation that lets your team carry on independently.
Sequence
How an integration project runs
The same four steps as in all our projects – except that here there are always at least two systems involved that nobody controls on their own.
Analysing systems and data flows
Over one to two weeks we map which systems are involved, which interfaces they really offer, which data has to go where and which system leads for each. That includes test access and a look at real records, not just the vendor documentation.
Plan and interface contract
In about a week the target architecture takes shape: data model, field mapping, rules for conflicts and failures and – where we build an API of our own – the OpenAPI specification. You see in advance what gets connected first and how you will know it works.
Building against test systems
We work iteratively and start against test or sandbox environments wherever the other side provides them. Every mapping is tested and versioned. Only once the sync demonstrably holds there does it go live with real data – stage by stage, not all at once.
Handover and operations
You receive the code, credentials, specification and runbooks for the usual incidents: what to do when a counterpart goes down or a record gets stuck? Your team takes over after a walkthrough – or we keep operating the integration if you want us to.
Example
A typical case: three systems, no shared truth
An assumed scenario, of a kind that comes up often in this or a similar form.
Not a client project
Suppose a wholesaler keeps its customers in a CRM, processes orders in an ERP and also sells through an online shop. Sales creates new customers in the CRM, and accounts type them into the ERP a second time. Shop orders arrive by email and are re-keyed by hand. Once a night an import script reconciles stock levels – at least on the nights it does not fail.
What typically follows is that nobody fully trusts the numbers. Sales sees outdated stock, customer addresses differ from one system to the next, and when the script breaks, somebody only notices once an item has been sold twice. The real question is rarely technical but organisational: which system is the authoritative source for which data, and what should happen when two of them disagree?
In a case like this we would settle exactly that question in writing first, then connect step by step: for example customer master data from CRM to ERP first, then shop orders straight into the ERP via webhook, and finally stock levels in the other direction. Each connection gets failure handling and a log, and each stage is useful on its own. Whether and to what extent this pays off is shown by the analysis – not by this example.
Technology
Open standards, not home-grown protocols
In API development we rely on open standards: new interfaces are built as REST APIs with an OpenAPI specification, authentication via OAuth 2.0 and webhooks for events. For the logic in between we mostly use TypeScript on Node.js, or Go; intermediate state and queues live in PostgreSQL or Redis. Where your organisation already has a standard, we work inside it rather than setting up a second one next to it.
We take the other side as it is: modern APIs, older services, direct database access or file exchange. Every integration emits logs, metrics and traces via OpenTelemetry, so you can see what is actually moving between your systems. It runs in containers – on your servers, in your cloud or, if you prefer, operated by us.
- OpenAPI
- REST
- Webhooks
- OAuth 2.0
- TypeScript
- Go
- PostgreSQL
- OpenTelemetry
FAQ
Frequently asked questions about API development
What people actually ask about APIs and integrations in first calls.
How much does it cost to build an API integration?
The effort depends mostly on the other side: is there a documented API, how many kinds of data move in which direction, and how clean is the data? Smaller tools and automations start in the four-figure range, from around €1,000; full applications typically land in the five figures depending on scope, larger platforms above that. After the analysis you receive an estimate with a price range.
What is the difference between an API and an interface?
In everyday use, usually none. “Interface” is the umbrella term for any connection between systems – including file exports or direct database access. An API is an interface built explicitly for other programs, today mostly a REST API over HTTP. Wherever possible we use APIs with an OpenAPI specification, because they can be tested, versioned and documented.
Can you integrate our ERP if it has no open API?
Often, but not always. Many older systems at least offer a data export, database access or an import folder that a sync can be built on. How robust that is, and what the vendor permits, we clarify during the analysis – before you spend money on an ERP integration that will not hold up in production.
What happens when one of the systems goes down?
That is what the failure handling is for. Messages that cannot be delivered go into a queue and are retried with increasing intervals. Duplicate deliveries are detected so that no order is created twice. If a record fails permanently, it is not dropped but reported – with a log, so your team or we can step in precisely.
Can integrations be built in a GDPR-compliant way?
We put the technical groundwork in place: encrypted transport, access via OAuth 2.0 or narrowly scoped keys, only the fields that are genuinely needed, and operation inside the EU or on your own servers. Logs contain as little personal data as possible. The legal assessment stays with your data protection officer or legal counsel.
More services
What often comes with it
Web applications & business tools
Internal tools and customer portals that mirror how the work is actually done, instead of complicating it.
- TypeScript
- React
- Next.js
- PostgreSQL
AI assistants & LLM integration
Assistants and chatbots that work on your own data and can show where an answer came from.
- LLM
- RAG
- Vector search
- MCP
Process automation
Recurring work that runs without manual steps in between – with explicit failure handling.
- Workflows
- Queues
- Event-driven
- Cron
Which systems need to talk to each other?
Tell us which systems are involved and what is currently done by hand. You get an honest assessment of whether and how the connection can be built.