Integrations & Connections

An integration starts with a sober inventory. Which system owns which data, in which direction does it flow, and what happens when the two disagree. We build a field list with source, target, data type and conversion rule. That is where the awkward questions surface: differing tax rates, units, date formats, country codes, and article numbers that do not look the same in both systems.

Technically we work with whatever the target system offers. Usually that is a REST API with JSON, sometimes GraphQL, and with older inventory systems SOAP, CSV or an XML export dropped on an SFTP directory. We use webhooks wherever a system reports events on its own, a paid order for example.

Before go live the whole path runs against a test instance. We push real records through it, including the ugly ones: cancellations, partial deliveries, a customer without a VAT ID, an article without a weight. Only once those cases pass cleanly do we switch the integration to production.

The most common trigger is double entry. Orders are placed in the shop and then typed into the inventory system by hand, stock levels are maintained through a weekly list, invoices are created a second time in accounting. Every one of these steps costs time and produces discrepancies that somebody has to chase down later.

The second trigger is growth. As long as only a handful of orders come in per day, manual work goes unnoticed. Once volume rises or marketplaces and a second shop join the picture, the transfer becomes the bottleneck. New requirements start projects too, for instance when customer group pricing should come from the ERP rather than the shop.

An automated pipeline makes less sense at very small volumes, for processes that still change every month, or while data quality in the source system is poor. An interface speeds up mistakes as well. Cleaning up master data therefore comes before automation, not after it.

The happy path is quick to build. The effort sits in the exceptions. We work with a queue instead of direct calls, so that an unreachable target system never swallows an order. Failed transfers are retried with increasing delay and, after several attempts, land in a list somebody can review.

Idempotency matters: an order sent twice must not create two orders. That requires a unique key per transaction that both sides know. Provider rate limits matter just as much. Many systems cap requests per minute, which becomes obvious the moment you run an initial import with several thousand articles.

Then there is visibility. We log every transfer with timestamp, payload and response, and set up an alert when a pipeline has been quiet for unusually long. Credentials live in environment variables, not in the code. We also record which system wins in case of a conflict, so nobody has to guess when the two disagree.