English 
Nederlands 
Español 
Integration problems rarely look like integration problems from the outside. They look like a dispatcher retyping an order into the TMS, a warehouse system that disagrees with the ERP about stock, or an invoice that arrives as a PDF when everyone expected a message. The fix is the same: define the data once, move it automatically, and watch it when it stops moving.
Map, move, monitor
- 01
Map
We start from the data, not the protocol: which field in your system corresponds to which field in your counterparty's, what the valid values are, and what to do when one is missing.
Ambiguity is resolved on paper before anything is coded.
- 02
Move
Orders, status updates, invoices and master data travel between systems in the format and transport your counterparties require, triggered by events rather than by someone remembering to export a file.
- 03
Monitor
Every message is logged with its status.
When something fails, it is visible with the payload that failed — not discovered a week later when a customer calls about an order nobody received.
What you get
- Integrations between TMS, WMS, ERP, carrier platforms and customs environments
- Mapping and validation for the formats your counterparties dictate
- Event-driven flows: no scheduled exports, no manual file handovers
- Message log with retries and alerting when a flow stops
What we connect
The systems in a logistics operation were rarely bought together, and they were rarely bought to talk to each other. Our work is the layer in between: reading what one system publishes and writing it into the other in a shape it accepts.
That includes the internal systems your team uses daily and the external ones your partners and authorities run.
Typical integration points
- TMS ↔ WMS: orders, stock movements, picking and shipping confirmations
- ERP ↔ operational systems: master data, invoicing, service and maintenance records
- Carrier and parcel platforms: labels, tracking events, status updates
- Customs environments and declaration systems, including document data feeds
Formats and transports
The format is dictated by the other side of the connection, not by preference: flat files and CSV where a partner still exchanges files, XML and JSON where an API exists, and the EDI messages your customers or carriers mandate.
The same applies to transport — SFTP, AS2, API endpoints or a shared folder — and to the timing: real time where a status has to be current, batch where a nightly run is genuinely enough.
- CSV and fixed-width flat files for partners who still exchange files
- XML and JSON APIs, including REST and SOAP endpoints
- EDI messages in the structure your counterparty specifies
- Transport over SFTP, AS2 or direct API calls, with retries and acknowledgement handling
When an integration stops working
Integrations fail quietly by default: a rejected message, a field that changed meaning, a partner that stopped sending. Nobody notices until an operational consequence shows up.
We treat monitoring as part of the deliverable. Each flow reports whether messages arrived, whether they were accepted, and what the payload looked like when they were not.
- Status per message, with the failing payload retained for inspection
- Automatic retries with backoff, and alerts when a flow stays broken
- Replay of a failed message once the cause is fixed, without manual re-entry
- Documented field mapping, so a future change is a specification edit rather than an archaeology project
Frequently asked questions
Which message formats and transports do you support?
The ones your counterparties require. In practice that means CSV and flat files, XML and JSON over APIs, and EDI messages in the structure your customers or carriers specify, carried over SFTP, AS2 or direct API calls. Tell us what your partners mandate and we will confirm the specifics for your case.
Can you integrate systems that have no API?
Yes. Where a system only exposes files, a database, or a screen, we build the integration around what it does offer — scheduled file exchange, a direct database interface, or a controlled automation — and document the trade-offs of that choice.
Do you replace our systems or connect them?
We connect them. The integration layer sits between the systems you already run; it does not require replacing your TMS, WMS or ERP to work.
What happens when a partner changes their format?
The mapping is documented, so a change is a specification edit rather than a rewrite. Validation catches messages that no longer match before they reach your operational systems.
How do we know an integration is healthy?
Every message is logged with its status, and a flow that stops accepting messages raises an alert. You can see what arrived, what was rejected, and what was retried, without asking a developer to read a log file.
The other data capabilities
Capture, extraction and communication are one pipeline. Most operations start where the pain is highest and extend from there.
Which two systems still need a human between them?
Tell us where data is being copied by hand — order entry, stock reconciliation, status updates, invoicing — and we will map what an integration between those systems would look like, including the format and transport your partners require.
Related work
Case studies
