Integration that survives the next vendor update.
Versioned, monitored, idempotent connections between systems — designed so a partner changing their API is an alert rather than an outage you learn about from a customer.
Why integrations rot
Most integrations are written once, work, and are never touched again — until a partner deprecates an endpoint or changes a field type. Because there is no monitoring and no version strategy, the failure is discovered downstream, often by a customer, often days later.
- Integrations exist but nobody knows how many or what they depend on.
- A failure is noticed when data is missing rather than when the call fails.
- Credentials are shared, long-lived and stored somewhere uncomfortable.
- A retry after a failure sometimes creates a duplicate, so nobody retries.
What we build
Integrations engineered as production services: authenticated properly, versioned deliberately, safe to retry, and observable enough that failure is loud.
- An inventory of integrations and what depends on each
- Authentication using short-lived, scoped credentials held in a secret store
- Idempotency keys so a retry cannot duplicate an operation
- Backoff, dead-letter handling and a documented replay path
- Contract testing against partner APIs to catch breaking changes early
- Alerting on failure rate, latency and schema drift
How it runs
Built on the assumption that the network, the partner and the payload will all fail eventually.
- 01Inventory and prioritise
What integrations exist, what breaks if each stops, and which are worth hardening first.
- 02Fix authentication
Scoped, rotatable credentials in a secret store, replacing shared keys in configuration files.
- 03Make operations safe to retry
Idempotency so a transient failure can be retried without a duplicate transaction.
- 04Handle failure explicitly
Backoff, dead-letter queues and replay, so a partner outage is a delay rather than data loss.
- 05Observe
Failure rate, latency and schema changes monitored, with alerts to the team that owns the flow.
What changes once it is running
What treating integrations as production services changes.
Failures announce themselves
A broken integration alerts the owning team instead of surfacing as a customer complaint.
Retries are safe
Idempotency means recovery is routine rather than a decision somebody has to be brave about.
Partner changes land softly
Contract testing catches a breaking change in a test run rather than in production.
Credentials stop being a liability
Short-lived, scoped and rotatable, rather than a shared key in a configuration file.
How an engagement is shaped
The inventory usually surprises people, which is a good reason to start there.
Inventory and risk review
One to two weeks cataloguing what exists, what it depends on, and where the fragility concentrates.
Harden and rebuild
Highest-risk integrations first, rebuilt to the standard above. Lower-risk flows can be left alone deliberately.
Operate
Monitoring, alerting and change response as partner APIs evolve.
Common questions
The things buyers ask before they commit. If yours is not here, it is a good first question for the assessment.
- Do we need an integration platform?
- Sometimes. Below a certain number of flows, a platform adds licence cost and a new thing to operate without reducing complexity. We size that against your actual integration count.
- What about partners with poor or undocumented APIs?
- We isolate them behind an adapter, so their instability is contained to one component instead of spreading through your systems. It is not a cure, but it makes the blast radius small.
- Can you work with integrations we already have?
- Yes, and that is usually the cheaper path. Adding monitoring, idempotency and credential hygiene to existing flows delivers most of the resilience without a rewrite.
Which integration would hurt most if it stopped?
Start with that one. If nobody is sure, the inventory is the first piece of work.