Blast Radius

The question before any change to a published API is the same one every time: if we do this, who breaks? It is normally answered by asking around, reading a dependency diagram someone drew a year ago, and shipping anyway.

Blast radius answers it from what is actually true right now — live subscriptions and the recorded dependency graph — for a given API and, if you narrow it, a given major version.

What The Report Gives You

Direct consumers affected. Active subscriptions to this API from consumers inside your own tenant, including those who subscribed through a product this API is a member of rather than to the API directly. Subscriptions that are pending or revoked are not counted: they are not consuming traffic, so a contract change does not break them.

Federated consumers affected. Active subscriptions held by consumers in other tenants, aggregated by how many organisations are involved as well as how many subscriptions.

Downstream APIs affected. The APIs in your estate that depend on this one. A dependency can be recorded from either end — the consuming API declaring that it consumes this one, or this API declaring that it produces for another — and each downstream API is counted once regardless of which side wrote it down. Only completed dependencies count as live impact; those still planned or in progress are shown separately, because reporting intent as impact is how a change-risk number stops being believed.

Tip

Narrow to a major version and the direct count narrows with it. Consumers who subscribed through a product are affected by any version change to a member API, so they remain in scope — which is usually the part a manual assessment misses.

The Part Nobody Else Can Answer

A vendor whose view stops at your organisation can only tell you about consumers inside it. Because subscriptions across tenants are first-class here, the report counts the consumers who found your API through the marketplace and live somewhere else entirely — the ones you have never met, whose integration you would otherwise break without knowing they existed.

If the federated count is zero, that is worth knowing too: the change is contained to your own tenant, and you can move faster.

When To Ask

Before a breaking change, as the input to a versioning decision. Before deprecating an operation. Before a migration, to know how many organisations you need to talk to. And during an incident, to establish the reach of the thing that is misbehaving.

It reads live state rather than a cached graph, so the answer reflects who is subscribed at the moment you ask, not who was subscribed when someone last updated a spreadsheet.

See also: API Topology · Versioning & Revisions · Compliance & Drift · Risk Management