Risk Management

Risk in an API programme is not only a security question. A contract that drifts from its implementation, an approval that was bypassed, an operation degrading under load and a design that breaches your own standards are all risks — and in most organisations each is owned by a different team, tracked in a different tool, and noticed at a different time.

Apiway classifies all of them on one scale, detected while traffic is served rather than by a scan that runs later.

Five Categories

Category	What it covers
Security	Refused credentials, entitlement violations, payload protection breaches, limit abuse
Governance	Approvals bypassed or overdue, changes that did not follow the flow
Compliance	Drift from the declared contract, and gaps against the regimes you report under
Performance	Degradation and limit pressure against what the service level declares
Design	Breaches of your own standards and architectural decisions

Each carries a severity of Info, Warning or Critical, and severity escalates with volume — so an isolated event stays quiet and a pattern surfaces.

Measured Against What You Declared

Rate limits and consumption are not judged against an arbitrary threshold somebody set in a console. They are judged against your OpenSLA — the machine-readable declaration of what you promised: throughput, quotas, limits and price.

That makes the same record answer two questions that are normally tracked in different places by different people:

Did a consumer exceed what they were entitled to? Limits are enforced per operation and per subscription while the request is served, so an over-limit call is rejected before your service is involved and recorded as a signal against that named consumer. Repeated pressure against a limit is usually one of two things — an integration retrying badly, or someone testing where the edge is — and both are worth knowing about early.

And did you honour what you promised them? Resource units are metered on the same pass, against the same declaration. So the question a customer eventually asks — “you committed to this throughput, did we get it” — is answerable from the record rather than reconstructed from logs after the complaint. A breach of your own service level is itself a risk in the performance category, raised against you rather than against them.

Because both sides derive from one declaration, they cannot disagree. There is no separate rate-limit configuration to keep in step with a contract stored elsewhere, and no reconciliation between what was sold and what is enforced.

Attribution Is What Makes It Useful

Because detection happens after the caller is authenticated, an event names a consumer, an agent or the person an agent acted for — not a source address. That single property is the difference between an alert queue and something worth acting on: a subscriber repeatedly attempting an operation they hold no entitlement for is a specific, investigable fact.

Authentication attempts are recorded too, and the platform distinguishes between the cases that look alike from outside: no credential presented, a credential that failed verification, a valid credential refused for the operation, and a caller with no recognised subscription. Those are four different problems — a broken integration, an expired secret, a permissions gap, and someone probing — and separating them is what turns a wall of 401s into a diagnosis.

Alerts, Pushed As They Happen

The gateway detects these events on the request itself. Risk management classifies their severity and pushes them on to you within about thirty seconds — attributed to the consumer, agent or person involved. You take them two ways:

• As a live stream you forward into whatever pages your on-call — see Real-Time Events below.
• As the current position, with GET /v1/risks, for a dashboard or a scheduled check.

Drift, upstream health, expiring credentials and version events are delivered by signed webhook instead — see Events to your on-call.

Event Categories

Category	Source	Severity
Protection Violation	Payload and request validation	Always Critical
Auth Failure (401 and 403, told apart)	Security stage	Escalates with volume
Approaching a Limit	Rate limit stage	Warning — raised before any call is refused
Rate Limit Breach	Rate limit stage	Escalates with volume

Severity escalates automatically based on event volume — a few auth failures might be typos, while a sustained burst signals an attack.

Risk Dashboard

The management UI surfaces risks at multiple levels:

Home Dashboard

The Active Risks KPI card shows a colour-coded indicator:

• Red — Critical risks requiring immediate attention
• Amber — Warning-level risks
• Green — No active risks

API Detail Page

Each API has a Risks tab showing:

• Direct risks for this API
• Dependency risks (risks on APIs this one depends on)
• Risk category breakdown

Tenant Risk Page

The /risks page provides a full risk dashboard:

• All risk categories with severity badges
• Complete risk list with filtering
• Trends over time

Real-Time Events

Risk events are published via Server-Sent Events (SSE). Your applications can subscribe for real-time notifications:

curl -N https://risk.api.apiway.net/v1/events/subscribe \
  -H "Authorization: Bearer $TOKEN" \
  -H "Accept: text/event-stream"

Events are tenant-isolated — you only receive events for your own tenant. The tenant is determined from the JWT, not a query parameter, so it can’t be forged.