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. The line carries the consumers themselves, by name, not only how many there are — a count tells you there is a problem, a list is what lets you notify people.

Federated consumers affected. Active subscriptions held by consumers in other tenants, aggregated by how many organisations are involved as well as how many subscriptions, and identifying which organisations they are. Consumers inside another tenant are not enumerated: you are entitled to know which organisations a change reaches, not to see another tenant’s internal structure.

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.

How the change classifies. Alongside who is affected, the report states what kind of change it is — Breaking, Additive or None — with the count of material differences and the two versions compared. Without it a number is ambiguous in the direction that matters most: forty-seven consumers is either forty-seven migrations or forty-seven people who will not notice.

The comparison is the same one the distribute gate performs — the nearest-previous distributed specification within the same major version — so the report and the gate never disagree. Edits to the information block are excluded, because changing a description is not a contract change. Where an API has only one distributed version there is nothing to compare against, and the report says so rather than reporting that nothing is broken; those are different answers.

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.