From data silo to data flow
In most companies the ERP owns prices, stock and orders, the PIM owns the product data, and the shop sells. In between, someone maintains data by hand or moves it around as an Excel export. That works until it stops working. We build interfaces that connect ERP, PIM, carriers and payment providers directly to shop and website: stock levels and prices flow into the shop automatically, orders flow back into the ERP, tracking numbers reach the customer.
The real effort is rarely in the transport, it is in the data mapping. Every system names its fields differently, units and variants follow their own logic, and for each type of data it has to be clear which system is the master. We settle that during scoping, before the first line of code. Clean data integration starts with that decision, not with the API.
Direct connection or middleware
We build REST and GraphQL APIs with PHP 8.x and Symfony. Where two systems exchange data, a direct connection is usually enough — lean, maintainable, quick to build. As soon as several systems are involved, middleware pays off: one place for mapping, validation, queues and logging, instead of a web of point-to-point connections that nobody can survey a few years later.
Not every data flow needs to be real time. Product data can run in a scheduled import; stock levels and orders usually should not. We decide per data type whether a batch, a near-time sync or an event-driven transfer fits — and use Redis for queues and caching where it helps.
Handling failure is the actual job
The classic case: the nightly import stops at record 40,000, nobody notices, and by mid-morning customers are ordering items that no longer exist. Failures like this are a question of when, not whether — every system on the other end will eventually send faulty or incomplete data. An interface is only finished once it can deal with that.
So validation sits in front of the import, not behind it: faulty records are sorted out and reported, the rest goes through. Processes are idempotent and restartable — an aborted import can be run again without risk. And every interface in production is monitored: faults reach us as an alert, not as a customer complaint.
Documentation is part of the interface
Plenty of interfaces have been running for years without anyone knowing exactly what they do. The developer has moved on, there is no documentation, and every change feels like open-heart surgery. We take such cases on: we read the code, the logs and the database, reconstruct the data flows and write them down — as the basis for repair or rebuild.
For everything we build ourselves, documentation is part of the work from the start: data flows, mappings, error cases, and who to call on the other side. Planning, build and operation come from one team at Sharpness Solutions in Oldenburg — the developers who build an interface also run it. That changes how it gets built.