API and system integration

Integration is where most enterprise software actually fails, and it fails in a specific way: the happy path is built in a fortnight and then eighteen months are spent on duplicate records, silent retries and a nightly job nobody can explain. We build integrations the other way round — idempotency, replay, reconciliation and observability first, because those are what determine whether the thing can be operated. Silverline Hospitality’s booking, payment and property-management systems now reconcile automatically overnight; the finance team stopped spending two days a month matching transactions by hand.

• 01

  Idempotent by construction. A retried webhook, a duplicated message or a replayed batch produces one record, not three, and that is tested rather than assumed.

• 02

  Reconciliation as a first-class deliverable: a daily report that proves both sides agree, and names the exceptions when they do not.

• 03

  Failures are visible. Dead-letter queues, alerting on backlog depth, and a replay procedure an operator can run without a developer.

• 04

  Rate limits, retries and back-off designed against the third party’s actual published limits, so an integration does not take itself offline under load.

• 05

  Contract-tested against consumers, so a change to your API breaks a build rather than someone else’s production system.

1. 01

   Map the flows

   Which system owns which field, in which direction data moves, and what happens on conflict. Most integration disputes are actually undeclared ownership, and naming the owner resolves them before any code exists.

2. 02

   Design for failure

   Idempotency keys, retry and back-off policy, dead-letter handling and the replay path. We design these before the happy path, because retrofitting them means reprocessing history.

3. 03

   Build and contract-test

   Implementation with contract tests on both sides where we control both, and recorded fixtures where we do not. Sandbox credentials are obtained early, because that is frequently the long pole.

4. 04

   Reconcile and cut over

   The integration runs alongside the existing process, producing a daily reconciliation report, until the two agree for a full cycle. Only then does the manual process stop.

• The integration, deployed, with source and pipeline in your repository.
• Flow map naming the system of record for every synchronised field.
• OpenAPI specification and a published change policy for any API you expose.
• Daily reconciliation report and an operator-runnable replay procedure.
• Monitoring and alerting on backlog depth, error rate and end-to-end latency.
• Credential and secret handling documented, with rotation procedure.

• 01Can you integrate with a system that has no API?

  Usually. Database-level integration with a strict read contract, file exchange on a schedule, or a screen-driven adapter for the genuinely closed products. All three are worse than an API and all three are survivable when they are built with reconciliation and monitoring. What we will not do is build one quietly and hope it holds.

• 02Should we buy an integration platform instead?

  For a large number of simple, standard connections between well-known products, yes — an integration platform will be cheaper and faster. For a handful of connections carrying real business logic, the platform becomes a place where logic hides from source control and testing. We will tell you which situation you are in.

• 03What about WhatsApp and other messaging channels?

  We build on the official business APIs, including the template approval process and the messaging windows, which are the two things that catch teams out. Messaging is normally paired with an assistant or an automation on the other end, so the channel and what answers on it get designed together.

• AUT

  Business automation

  Removing the manual steps between systems — workflow, document handling, sales and service processes, with or without AI.

  /services/business-automation
• DBS

  Database solutions

  Design, migration, performance and recovery — mostly SQL Server, and mostly for systems whose data has outgrown its original design.

  /services/database-solutions
• AI

  AI and generative AI solutions

  Assistants, chatbots, voice agents and generative features that are wired into your actual systems and measured against a baseline.

  /services/ai-and-generative-ai