Your software landscape seamlessly connected

The same categories keep coming back: ERP and accounting (Exact Online, AFAS, SAP, Dynamics, Twinfield), CRM (HubSpot, Salesforce, Pipedrive), e-commerce and marketplaces (Shopify, WooCommerce, Magento, Bol.com), payments (Stripe, Mollie, Adyen), shipping and logistics (SendCloud, carrier portals) and HR or time-tracking packages. We also connect many custom systems over REST or GraphQL, and older systems over SOAP or database views. Per-system guides live on /api-koppelingen. If your package is not listed, that is rarely a blocker: what decides whether an integration is possible is not the name of the system, but whether data can get in and out in a controlled way.

One direction, one system, good documentation and a sandbox: then we are talking one to three weeks including tests. Two-way traffic with conflict rules, or a system without a sandbox where you can only try things in production, runs to six to ten weeks. Legacy without an API is a separate track, because the first weeks go into working out how data comes out reliably. We only give a plan after a short inventory in which we read the documentation, request test access and look at data volume. Requesting API access from a vendor is more often the delaying factor than the build itself.

Then we look for another controlled route. In order of preference: a SOAP service if one still exists, a database view or read-only replica, a scheduled export over SFTP or a shared network drive with CSV or XML files, and only as a last resort a scripted browser route. With file exchange we handle the things that always go wrong there: unique filenames, archiving processed files, ignoring half-written files, and detecting that an expected export never arrived today. Sometimes the shortest path is asking: vendors build an endpoint more often than expected when a customer requests it concretely. We help formulate that request.

Traffic always over TLS, authentication via OAuth 2.0 with the smallest workable scope or API keys per environment, and credentials in a secrets manager rather than in code, config or a spreadsheet. That makes keys rotatable without rebuilding the integration. For healthcare and finance we build audit trails recording which data was sent when and by which process, which makes GDPR accountability and NEN 7510 requirements practical. Beyond that: data minimisation (only the fields the receiver needs), EU hosting and logging with personal data masked. An integration is a door between two systems; who may pass through it and what crosses it should be explicitly defined.

Every API throttles at some point, and it happens on your busiest day. So we do not put direct calls between systems but a queue in between. Messages are processed at a controlled pace, stay queued when the other side is slow, and failed attempts are retried with exponential backoff: first after seconds, then after minutes. Calls are idempotent, so a retry never produces a duplicate order or duplicate invoice. Whatever fails after a number of attempts goes to a dead letter queue with the original payload, so it can be reprocessed manually or after a fix. Nothing disappears silently.

This is almost always the real work. Two systems rarely store the same thing: addresses with house number and suffix in one field versus three separate fields, dates as timezone-less text versus UTC, amounts in euros with a comma versus cents as an integer, VAT inclusive or exclusive, and customer numbers that are authoritative in one system and meaningless in the other. We record per field which system holds the truth, how we normalise, and what happens with a value that fits nowhere. Records failing validation land on a review list instead of being silently skipped.

Every integration we deliver has a healthcheck that verifies every five minutes whether the last synchronisation succeeded and whether the queue is backing up. On deviations an alert goes out before your customer service notices something is missing. We also track changelogs and deprecation notices from the vendors you use. For breaking changes we work with an agreement in the retainer: reporting and scheduling within a fixed window, with priority handling when a vendor retires an endpoint on short notice. Without that safety net you usually discover a broken integration through a customer, and then repair the fault plus the backlog.

Often, and rarely by switching the existing integration off straight away. We build the new flow alongside it and first let it run without writing: the same data, only logged and compared against what the old integration does. Differences then become visible without risk to operations. If the picture holds for days or weeks, we cut over per data flow and keep the old route available a while longer. Added benefit: that parallel period finally makes clear what the old integration actually did, which with undocumented scripts is often the most important missing knowledge.

One flow between two systems with a clean API usually stays within a few thousand euros, including tests and monitoring. Once it becomes a landscape, for example webshop, ERP, stock and shipping all having to follow each other, it is no longer four separate integrations but a set of agreements about which system is authoritative where; that is where the extra work and therefore the investment sits. Legacy without an API and two-way traffic with conflict rules are the two biggest cost drivers. Alongside the build, budget for ongoing monitoring and maintenance. For a first range use /calculator; a substantiated price follows the inventory.

Real-time is not automatically better. For a stock level customers can see, or a payment that must release an order, you want events and webhooks within seconds. For ledger entries, daily reports or price lists, an overnight batch is calmer, cheaper and easier to verify, because you look at one overview once a day. Many landscapes therefore end up mixed: real-time where the user waits, batch where the administration waits. We choose per data flow based on how bad it is if data is an hour old, and how many calls the source system can handle.

We test against sandbox environments where they exist and use automated tests per integration, but the gain is in the exceptions: an order cancelled mid-synchronisation, a credit note, a customer that exists twice, a field that turns out to be optional, a timeout halfway through a batch. We deliberately play those scenarios out before going live. Where there is no sandbox we test in production with flagged test records and a limited set. Nobody can rule out surprises entirely; what we can do is make sure a surprise becomes visible instead of quietly propagating into your administration.

Every flow logs what went in, what came out and which attempt it was, with personal data masked. If a queue backs up or a healthcheck fails, the team gets an alert with the context attached. During an incident we can pause one flow without touching the rest, roll back a release, and reprocess the queue after the fix. Because calls are idempotent, that produces no duplicate bookings. Afterwards comes a short write-up: what happened, what the temporary measure is and which change prevents a repeat. Retainer clients have agreed response times for this.

Technically there is no limit; organisationally there is. So we start with the flow that removes the most manual retyping and expand from there. Each integration gets its own module with its own logging and monitoring, so an outage at one vendor does not drag the rest down. What really becomes decisive beyond a handful of systems is a central view of which system is authoritative per data element: without that agreement systems overwrite each other and nobody is sure which value is correct. Two systems or twenty, the same approach; only the time spent on those agreements differs.

It makes sense when volumes are low, the logic is simple and speed matters more than control: Make or Zapier puts a simple flow live in days and sometimes that is exactly enough. It makes less sense once you process tens of thousands of records per month (per-task pricing adds up), once real business rules are involved that you want to be able to test, or once an error costs money and you need traceability. Also important: knowledge inside a visual flow is hard to transfer and lives in the platform, not with you. We advise per situation and sometimes build a mix: iPaaS for peripheral flows, custom for the core.