integration

Systems that talk to each other

Middleware between the systems your business runs on. Orders, stock, invoices, statuses and documents moving between platforms that were never designed to meet, validated on the way through, and logged so you can see exactly what happened. There are plenty of off-the-shelf connectors; we're the people you call when none of them quite fit.

What it looks like from where you're sitting

Someone exports a CSV from one system and imports it into another every morning. When they're off, it doesn't happen.

A big customer wants to send orders by API. The system you run the business on only understands flat files, or a screen. The conversation stalls.

There's an integration already. Nobody knows how it works, it fails quietly, and the person who built it has gone.

What we do about it

When a connector won't do, a layer in the middle that owns the problem

Map

Every field on one side matched to its meaning on the other, written down, versioned, and changeable without redeploying anything.

Validate

Bad data gets stopped at the door with a clear reason, not passed through to break something downstream. Rejections are visible and actionable.

Route

REST, SFTP, EDI, webhooks, email attachments, whatever each system speaks. Both directions. Retries and back-off when the other end is down.

Log

Every message in and out, searchable. When a customer asks where order 48213 went, the answer takes thirty seconds, not an afternoon.

Alert

Failures, backlogs and silences reported to people who can act, before the customer notices.

Run

Hosted, monitored, patched and supported. New customer connections added as standard work, not as a project.

For the technical reader

How it's built

Message-oriented: every inbound document becomes a record with a lifecycle (received, validated, transformed, delivered, acknowledged, failed) so nothing is lost between steps and everything can be replayed. Transformations are configuration, not code, so a new customer format is a mapping file rather than a release.

Failure is the normal case we design for: idempotent handlers, dead-letter queues, explicit rejection reasons sent back to the source, and dashboards that show queue depth and age. Deployed through a pipeline, with the schema and mappings under version control.

languages · go, php storage · postgres, mysql transports · rest, sftp (sftpgo), edi, webhooks, smtp systems · shopify, woocommerce, sage, xero, dynamics, netsuite, sap, wms platforms, in-house databases ops · ubuntu, caddy, github actions, digitalocean patterns · idempotency, dlq, replay, versioned mappings
example · one of several

Connecting a 3PL's customers to its warehouse system

[Case study placeholder. Dozens of customer formats in, one WMS out, both directions. Situation, approach, stack, and a real number for volume and uptime. To be written once what can be referenced is confirmed.]

Two systems, one spreadsheet in between?

Tell us which systems and what moves between them. We'll tell you what the middle layer would look like and roughly what it takes.