Integrations & middleware
Connect Shopify to the systems you actually run
The storefront is rarely the problem. Projects derail where Shopify meets inventory, accounting and the warehouse. We build the interfaces in between: a clean API connection, middleware when several systems have to talk, or nothing at all when an existing connector already solves it.

What gets connected
The four systems German stores hang on
Almost every enquiry we get is some combination of these four. Which one dominates your project decides the effort and the architecture far more than your product count does.

ERP and inventory
JTL, Xentral, plentymarkets, microtech, SAP Business One, Microsoft Dynamics. Articles, stock, prices and orders in both directions. The real work is rarely the API — it is deciding which system wins when the two disagree.

Accounting and tax
DATEV, Lexware and the document chain around them. Invoices, credit notes, OSS, and the question of who issues the invoice number. Unglamorous, audit-relevant, and the area where an improvised solution gets most expensive.

Warehouse, shipping and returns
Fulfilment providers, DHL and Packstation, returns portals, tracking back into the store. This is where the errors your customers see first are made, so we build the status callbacks and the failure cases, not just the happy path.

CRM, PIM and marketing
Klaviyo, HubSpot, product data management, customer segments. Technically the easiest of the four and the most delicate in substance: which data may leave, how long it stays there, and what happens on a deletion request.
How we work
The decision first, then the code
The most expensive integration projects are the ones where building started too early. Four steps, and the first one saves the most money.

Check whether an app already solves it
JTL, Xentral and plentymarkets ship their own apps on the Shopify App Store. If one of them covers your case we say so and build nothing. Custom code is the answer when your process is what differentiates you, not when it is merely inconvenient.

Fix the data direction and the conflict rules
Who owns the truth for prices, who for stock, who for customer records. What happens when both sides change the same field. Answering that in writing takes one workshop and prevents the class of bug nobody can reproduce.

Build it, including the failure cases
Straight against the Shopify APIs when the connection is lean, through middleware when several systems have to talk. Either way with retries, logging, and one place where you can see what did not go through last night.

Hand over, then watch it
An integration is never finished: systems change their APIs, catalogues grow, processes shift. We hand over with documentation and monitoring, and if you want it, watching the thing stays part of ongoing store management.
Trusted by brands worldwide
Brands whose Shopify stores are wired into real back-office systems
The logos below are stores in production, not pilots. For most of them the hard part sits behind the storefront.
Integrations FAQ
What merchants ask about ERP and interface projects
Straight answers on connector versus custom, middleware, data ownership, and when we advise against building.


Complicated system estate?
Describe one order to us.
Take the connector if it fits your process. It is cheaper, it is maintained, and you are not its only user. Custom starts making sense once you need fields it does not know, logic it cannot express, or once you catch yourself bending your process to suit the tool rather than the other way round. We check the JTL, Xentral and plentymarkets apps before quoting custom code.
With two systems, usually not — a direct connection through the Shopify APIs is leaner and has fewer parts to break. From three or four systems all touching the same data, middleware pays for itself because it creates one place where mapping, retries and logs live. The decision follows the number of participants, not the size of the store.
Real, which is why we never switch an interface on in one step. Read-only against test data first, then writing against a single test range, then the full run with a way back. The failure that actually hurts is not an interface that stops — it is one that writes wrong stock levels while looking like it works.
You do. The code sits in your repository, the credentials in your systems, the documentation with your team. An integration only we can operate is a dependency, not a deliverable.
Yes, two ways. Scheduled sync is robust and lags by however long the interval is. Live resolution is always current and puts your ERP's uptime in the buying path. We choose based on how often your data actually changes, which for most merchants is less often than they assume.
It depends on the number of systems, the direction of the data flow, and how clean your data is today. That last one surprises people most: connecting a messy article master costs more than the interface itself. We scope first and price each block on its own.
Related
Around the connection
The services an integration project usually arrives with.

Martin Winkler
Co-Founder & CEO
Mark Chang
Founder & CTO