Skip to content

Discuss your project

Integrations

Systems that share data without manual entry

Your online shop, accounting system and stock system each know part of the picture. An integration lets them share that data. If a standard integration is enough, we will say so; if not, we build one, with clear agreements on what happens when something fails.

Discuss your integration

An API integration allows two systems to exchange data in a controlled manner

An API is the agreed input to a system: what other software can request, what they can change, and with what key. A link uses those inputs to transfer data from one system to another, for example a paid order from your online shop to your accounting package.

This page is for those who have systems that don’t talk to each other. You notice this in retyping, in export files that go back and forth every week, or in figures that differ slightly in two systems. A link can also be made separately from one of our websites or apps: you do not have to purchase anything else from us.

A standard integration is often enough

A custom integration fits if

  • There is no standard integration between your two systems

  • The default link is missing fields or lines that count for you

  • There are more than two systems involved and the order matters

  • You want to be able to see what didn’t get through, and why

A custom integration does not fit as well as

  • Your online shop or accounting package already offers a link that does what you need

  • A linking service already connects your packages, for a subscription that suits you

  • This involves a handful of data per month, which you can transfer more quickly by hand

  • One of the systems has no API or any other way to exchange data

If there is a standard integration, we will help you choose and set it up, and we will tell you where it falls short. If a system does not have an API, we will discuss whether an export file or another system is a way out.

Four appointments before we build a integration

A integration rarely goes wrong due to technology, but more often due to what was not agreed. These four points are therefore fixed for construction.

Which system is the source

For each piece of data we agree which system is leading. If the stock is in both your inventory system and your online shop, it must be determined which of the two is correct if they differ. Otherwise they overwrite each other.

Which way the data is going

Some data goes in one direction, such as an order from the online shop to the accounting department. Others go back and forth, such as a customer address that can be changed in two places. Two-way traffic requires more agreements and more testing.

How you notice when something goes wrong

A link can malfunction: a system is temporarily inaccessible, a field is missing or a key expires. We ensure that such an error becomes visible, with a notification or an overview of what did not go through, and that you can have it resent where possible.

How quickly a change comes through

Not every link is real-time, i.e. immediately at the moment of the change. Some systems report a change immediately, others are requested at fixed times, for example every fifteen minutes or once a night. What is possible depends on both systems; what is needed, of your process.

Three integrations that remove manual work

Possible applications, not completed projects. Each shows what it depends on.

Orders that flow into your accounts automatically

Problem

After every order, someone manually transfers the amount, payment and VAT to the accounting package. A typing error may only surface when it is time to file the VAT return.

Solution

An integration that sends every paid order to your accounting package as an entry or sales invoice, using the correct VAT code. Refunds are included as credit notes.

Data involved

Orders, customer details, amounts per VAT rate, payment status and refunds.

Benefit

Manual entry disappears, and your online shop and accounts show the same figures.

Depends on

Whether your accounting package has an API and what it allows, whether an existing standard integration is sufficient, and how your accountant wants to receive the entries.

Stock from one system, consistent everywhere

Problem

Stock sits in an inventory system, but the online shop only knows about it when someone uploads an export. In the meantime, you sell items that are no longer available.

Solution

An integration that sends stock changes from the inventory system to the online shop, and reports sold quantities from the online shop back. The inventory system remains the source of truth.

Data involved

Product codes, stock by location, quantities sold and, where applicable, expected deliveries.

Benefit

The online shop shows what is actually available, and you no longer need to move export files back and forth.

Depends on

Whether both systems use the same product codes, how quickly the inventory system reports changes, and how many products there are.

Delivery addresses ready in the route planner

Problem

You make deliveries yourself. Every morning, someone copies the previous day’s order addresses into the route planner, and a changed delivery time does not always make it in.

Solution

An integration that sends orders with delivery at a set time to the route planner, including address, time slot and notes. Once a route is planned, the customer can receive a message with the time slot.

Data involved

Orders with delivery address, chosen time slot, customer notes and route status.

Benefit

Planning starts with a complete list, and a customer change is included automatically.

Depends on

Whether the route planner has an API, when the list needs to be finalised, and which personal data the route planner is allowed to receive.

A integration requires maintenance

A integration is not a one-time job. The systems on both sides are changing, and the integration must keep up.

APIs change

Platforms turn off old inputs and request new ones. Shopify, for example, has called its REST Admin API legacy since October 2024 and asks new apps to use the GraphQL Admin API. Those who have a link must follow such changes.

Keys expire or are revoked

A link works with keys or accounts that grant access. If they are replaced, the integration must be included. We record where they are and who manages them.

Your process changes

A new shipping method, an extra VAT rate, a second warehouse: the link needs to know. We agree on further development, as well as checking whether everything is still going through.

From two systems to one stream of data

  1. Systems and data mapped.Which systems, which data, in which direction and how often. Based on real cases.

  2. Check standard integrations.We look at what the systems themselves offer and what integration services are available, and what they do not do.

  3. Review APIs.We read the documentation of both APIs: what is possible, what limits there are, and whether there is a test environment.

  4. Record appointments.Source, direction, error handling and pace, plus who gets notified if something doesn’t go through.

  5. Build and test.We first build against test data, then we test with real cases, including the difficult ones: a missing field, a duplicate order, a system that does not respond for a while.

  6. Go-live and monitoring.The integration goes live with an overview of what gets through and what doesn’t, and a description of what to do in the event of a malfunction.

What we need for a proposal

For a link, the proposal concerns the systems on both sides.

  • The names of the systems, and which subscription you have for each

  • Which data should be included and in which direction

  • Or you already know whether the systems have an API or a standard integration

  • A few real examples, such as an order and the booking that must follow from it

  • Who arranges access to your systems

  • Only during construction: keys or accounts that you create and can revoke. Never send passwords or keys via the form or by email

What a integration costs depends on both sides

Amounts are stated in the proposal. They determine these factors, and the costs per year are shown next to them.

  • Number of systems.Two systems are simpler than three waiting for each other.

  • Direction.One direction is simpler than data going back and forth.

  • Quality of the APIs.Well-described APIs with a test environment require less research than APIs without.

  • Exceptions.Refunds, partial deliveries, changed orders: every exception must be handled and tested.

  • Existing data.Whether old data needs to be cleaned up or aligned first, such as item numbers that do not match.

Recurring costs

  • Hosting the link

  • API or subscription costs of the linked systems

  • Costs of a integration service, if it is part of the solution

  • Maintenance: API change tracking, auditing, and recovery

Questions about links

Can I have a link made without your website or app?

Yes. A link between your existing online shop and your accounting package, for example, can stand alone.

How do I know if my systems have an API?

Often it’s in the package’s documentation or help center, under words like API, developers, or integrations. If you don’t know, name the packages; we will find that out.

What if one of the systems changes or is replaced?

If the API changes, the integration will adapt within the maintenance agreement. If a system is replaced, this is a new side of the integration and we will make a proposal for it.

Where does the clutch turn?

On hosting that we choose together, in your name or by appointment. We limit what the link stores to what is necessary to repair errors.

Links per platform, and customization

Tell us which systems do not communicate

The names of the systems and what is currently done by hand are enough to start. We first check whether a standard integration exists.

Discuss your integration