Integrations and APIs

What we connect

A software integration gets two or more systems talking to each other. Think of your accounting software and your webshop, your CRM and your planning software, or a machine in your factory and the system you track orders in.

An API is a controlled entry point that systems use to request and pass on data. So when we connect systems, we first look at one thing: does the system have an API? If it does, we can get started. Whatever changes in one system then shows up correctly in the other, with no typos along the way. Copy and paste doesn't belong in a job description.

Standard integration or custom work?

For a simple link between two widely used packages, a standard integration usually exists already. If that's enough, we'll say so, and you probably don't need us.

Custom work pays off when a system isn't widely used, a device has to pass on data, you have your own business rules, or data has to flow in more than one direction. We then build your company's requirements and rules into the integration itself.

For simple routines between apps, workflow tools can do the job; more on those under AI and automation.

Building your own API

Sometimes there's nothing to connect to: an older system has no API, or your own platform needs to share data with partners, an app or a webshop. Then you need an API of your own: a controlled entry point to your data, where you decide what goes out.

An API like this is often part of something bigger. On a platform, we build it as part of a web application. For data from several sources in one overview, it connects to dashboards.

How an integration project works

Not every integration at once. We start with the one that saves the most manual work, and after each phase you choose the next.

• Introduction and analysis: in the introductory call we map out your systems: which ones have an API, and where is data being retyped or exported today? We then work out which integrations are possible and in what order they pay off most; that research is on us.
• Design: an integration often has no screens. The design is mostly an agreement: which data goes where, and which system is the source of truth?
• Building in phases: phase 1 is the integration that saves the most retyping. You test early: you watch the first data arrive from one system in the other and tell us what's not right yet. That shapes the next phase.
• Launch and support: the integration takes over the retyping, while we keep an eye on things in the background.

Example: the door at De Dieu

For Sociëteit De Dieu, a members' club for founders, the three of us built a new members app and an admin dashboard in 2024 and 2025. One part of it belongs on this page: the door.

A member walks in with their own pass and shows up in the app among those present. To make that work, we built a custom integration with the door access system. Nobody has to keep a list.

It shows that an integration isn't limited to software packages. Here a physical door passes on data, and the management team sees it in the same platform as members, events and bookings. The full story is in the Members app for De Dieu case study.

What does an integration cost?

What an integration costs depends on what sits on both sides: how many systems take part, how well the other system is documented, whether data goes one way or several, whether data has to arrive straight away or at set times, and how many of your own business rules it needs. You keep the cost under control by starting small: first the integration that delivers the most, the rest in a later phase.