Mapping External Dependencies and APIs

Mapping external dependencies and APIs traces every outside interface a service calls, what that interface provides, and what the service does when it is unavailable, slow, or returns unexpected data. Modern services rarely stand alone. They call identity providers, payment gateways, data vendors, messaging platforms, and other external services through interfaces that the firm does not control. Those interfaces can change, degrade, or fail without warning, and the firm may learn about the problem only through customer complaints. A map that names each external interface, its role, and its fallback gives responders a place to start instead of a mystery to unravel.

An external dependency is any capability outside the firm that a service needs to complete its outcome, whether it is reached through an interface, a file transfer, a hosted platform, or a manual interaction with a supplier system. Interfaces deserve particular attention because they are often numerous and lightly documented. A service may call dozens of interfaces across its journey, from address validation to fraud screening to settlement, and each one can become a point of failure. The map should therefore list external interfaces alongside other suppliers, with enough detail to distinguish a critical interface, without which the service cannot complete, from a supporting interface whose loss merely degrades it.

For each external interface, the map should record the provider, the function it performs for the service, the data exchanged in broad terms, and the expected behaviour when it is unavailable. It should also record the owner inside the firm who manages the relationship, the contact route during an incident, and any alternative that exists, such as a cached result, a manual process, or a different provider. Version and change information matters too, because a provider may update its interface and require the firm to change its own code. A map that records the interface but not its change history will miss the risk that a routine provider update breaks the service.

Interface failures are often partial and ambiguous. An interface may respond slowly rather than failing outright, return incomplete data rather than an error, or fail for some requests but not others. The service may therefore appear to be running while producing incorrect or incomplete outcomes, which is harder to detect than a clean outage. The map should note, for each critical interface, how failure would be detected, what monitoring or alerting exists in broad terms, and what the service should do when results look suspicious. That detection note is as important as the fallback, because a fallback that is never triggered is no fallback at all.

Concentration arises when several services, or several steps within one service, call the same external provider or the same interface, often through different teams that are unaware of each other. A failure of that provider then becomes a multi-service incident, even though each service map individually shows only a modest dependency. The remedy is to aggregate interface use across services, so that shared external dependencies are visible at portfolio level as well as service level. The map for one service should therefore contribute to a wider view, and a team mapping a new service should check whether its chosen provider is already critical elsewhere before adding another dependency on it.

Test by simulating an interface failure in rehearsal, including a slow or partial failure, and asking responders to follow the map to the impact, the detection, and the workaround. The exercise should also test communication: can the firm reach the provider, obtain meaningful status information, and convey customer impact? If the rehearsal reveals an interface that was undocumented, a provider contact that is out of date, or a workaround that assumes the interface will return quickly, those are findings to own and fix. Under DORA in the EU, ICT third-party risk includes such external interfaces, and under FCA and PRA policy in the UK, third-party expectations are stated separately; both regimes are labelled where used in these guides.