Software engineering · Systems integration and APIs
Making the systems you already run talk properly
Contract-first APIs, event-driven messaging and connectors to the business systems you already have, built so a failure is retried and reported rather than discovered at month end.
Where this starts
The data exists, it just does not move
Most organisations do not have a data problem so much as a transfer problem. A record is created correctly in one system and then re-entered by a person into a second, because the integration was never built, or was built once by somebody who has since left and now fails without telling anyone. The cost is rarely counted, because it is spread thinly across people who have absorbed it into their working day.
What we usually find
- The same record typed into two systems by two different teams
- A nightly file transfer that fails quietly and is noticed at month end
- An integration that duplicates orders whenever it is retried
- A vendor API change that broke something, found first by a customer
- No record of which systems talk to which, or who owns each connection
- Reports that disagree between systems, with no way to say which is right
Our position
An integration without idempotency and a monitored dead letter queue is not an integration. It is a scheduled outage with an unknown date.
What the work covers
Contracts first, plumbing second
The failure mode in integration work is almost never the transport. It is an unclear contract and an undefined answer to what should happen when the other end is unavailable.
API design
Contract-first, with the specification agreed and published before implementation, so both sides build against the same thing and the consumer is not discovering the shape by trial and error.
Event-driven messaging
Publish and subscribe where systems should not wait on one another, with ordering, replay and poison message handling decided deliberately rather than discovered under load.
Idempotency and failure handling
Retries that cannot duplicate, dead letter queues that somebody watches, and backoff that stops a slow dependency turning into an outage across everything that touches it.
Business system connectors
ERP, CRM, finance, payments, logistics and marketplace platforms. The real work is usually less about the protocol than about reconciling two different models of the same business object.
Versioning
Changes shipped without breaking existing consumers, with a deprecation path and a way to see who is still on the old version before you remove it.
Partner and public APIs
Documentation, a sandbox, authentication and rate limits, so integrating with you is something a partner can complete without booking a call with your engineers.
How failures announce themselves
The difference is all on the unhappy path
A reliable integration and an unreliable one look identical while everything is working. These are the things that separate them when it is not.
- Contract tests
- Both sides tested against the published specification in the pipeline, so a breaking change fails a build rather than a customer order.
- Replay
- Messages retained and replayable, so recovery after an outage is a command rather than a manual reconstruction from log files and memory.
- Reconciliation
- Scheduled comparison of record counts and totals between systems, reported as a difference, which is how a silent failure becomes a visible one the same day.
- Alerting
- Dead letter depth and transfer age monitored, because an integration that has stopped entirely looks exactly like one with nothing to do.
- Catalogue
- A maintained inventory of connections, owners and contracts, generated from the running systems rather than kept by hand and left to go stale.
What you are left holding
- Published API specifications that both sides build against
- Integrations that retry safely and fail loudly
- Scheduled reconciliation between the systems that matter
- A catalogue of every connection and its owner
- A versioning and deprecation policy your partners can rely on
Tell us which two systems people are copying between
That is usually where the largest recoverable cost in the estate is sitting, and it is rarely the one being discussed.