Azure integration guide

Seven signs an API integration is becoming a business risk

Integration problems often appear first as manual work, unexplained data differences or support noise. Those symptoms can reveal a service the organisation no longer understands or controls.

By Chris Domville · 2 September 2026

1. People regularly reconcile systems by hand

Spreadsheets and manual comparisons are often compensating for missing identifiers, silent failures or unclear ownership. Record what people check and why—it describes the controls the integration should provide.

2. Retrying a message can create duplicate actions

Networks and dependencies fail. If a request cannot be retried safely, temporary faults can become duplicated orders, payments or records. Idempotency needs to be part of the contract and data design.

3. Failures are discovered by users or customers

Infrastructure monitoring may show that every component is running while transactions remain stuck. Operational monitoring should expose age, throughput, exceptions and business completion across the full path.

4. A small change requires coordinated releases

Tightly coupled interfaces force multiple teams to deploy together and increase the effect of apparently local changes. Versioned contracts, compatibility testing and clearer boundaries reduce that coordination risk.

5. Nobody can explain the data transformation

Field mappings and business rules hidden in code, database procedures or scheduled scripts create knowledge risk. Important transformations should be testable, documented and owned.

6. Credentials and permissions are difficult to rotate

Hard-coded secrets and shared service accounts turn routine security maintenance into a risky production change. Managed identity, central secret storage and least-privilege access make ownership clearer.

7. Support depends on one person

If only one developer understands how to diagnose and replay failures, the integration is not supportable. Dashboards, structured logs, runbooks and controlled recovery tools should reduce reliance on memory.

What an integration assessment should establish

FlowSystems, data, identifiers, transformations and expected completion.
FailureRetries, duplication, exceptions, recovery and reconciliation.
ControlIdentity, permissions, secrets, audit evidence and ownership.
OperationMonitoring, alerts, runbooks, capacity and change process.

Start with the integration that creates the most friction

A bounded assessment can map the real workflow and prioritise fixes before a replacement architecture is commissioned. Domville Tech provides Azure API and system integration assessment, remediation and delivery.

Recurring integration problems?

Trace the real failure path.

Discuss the integration