Request pipeline

Every SBI and Diameter request runs through one ordered filter chain before routing. The order is fixed; each filter can deny and short-circuit. Understanding the order tells you exactly what the proxy did — and didn't — do on any given request.

Pipeline overview

The full path from inbound to forwarded looks like this:

Code

The request filter chain is an ordered sequence of filters. A filter denies by returning an error; the chain short-circuits and the request is rejected without running the filters that follow. Routing runs after the chain allows the request — routing is not itself a filter.

Filter order

The request chain is a fixed-order slice. There is no per-filter priority knob for the chain itself; each filter is added only when its feature is configured.

#	Filter	Included when
1	Auth (OAuth2 / JWT)	`oauth2_required: true`
2	Policy (allow/deny)	always
3..N	Rate limit	one filter per entry in `rate_limits[]`
N+1	Transformation (request phase)	`transformation_rules[]` non-empty
next	Application server	`application_server` configured
last	Signature verification	`request_verification.enabled: true`

Decisions are logged, not audited

The proxy has no audit store. Each request's decision (allow or deny, the deny reason, the matched rule, and timing) is emitted as a structured JSON log line and counted in Prometheus metrics. Ship those logs to your log pipeline or SIEM. See Policy engine for the decision model and Setting up observability for the log and metric surface.

What each filter does

Auth

Validates the Authorization: Bearer … header against the configured OAuth2 / JWT settings. Tokens must be signed with RS256; the proxy verifies the signature against a configured public key or a key fetched by kid from a JWKS URL, which supports key rotation. It enforces required scopes and can optionally reject replayed tokens by jti. Requests with a missing, invalid, expired, or out-of-scope token are denied. The filter is skipped entirely when oauth2_required is false.

Policy

Evaluates the active policy rules in priority order — first match wins. Rules are sorted by priority ascending (lower value runs first), with the rule name as a deterministic tiebreak. Each PolicyRule has an action (allow / deny) and its conditions. If no rule matches, the configured default action applies. The v1 default is deny (fail-closed). See Policy engine for the full evaluation model.

Rate limit

One filter is added per entry in rate_limits[]. Each rate-limit rule is a token bucket keyed by consumer identity, SUPI, NF type, or a combination. When a bucket is exhausted the filter denies the request and the chain short-circuits. See Configuring rate limiting.

Transformation (request phase)

Applies header injection, removal, and rewriting, plus body field operations, to the request before forwarding. Request-phase rules run in priority order (lowest value first). The filter is added only when transformation_rules[] is non-empty. See Transformation engine.

Application server

When application_server is configured, the proxy asks an external verdict service after transformation and before routing. The filter is omitted unless that block is present.

Signature verification

When request_verification.enabled is true, a signature-verification filter is appended last (it comes from the config file, not the control-plane store).

Routing

Routing runs after the filter chain allows the request:

SBI: the routing engine picks a target producer.
Diameter: the routing engine picks a peer for the message's realm, retrying on the next peer if the first fails.

Routing reads the same control-plane store as the filter chain — routing rules, producer pool, weights, sticky-session table, drained-peer set. See Routing engine.

Response stage

After the producer (or peer) answers, the response runs through a separate response stage before it reaches the consumer.

	SBI	Diameter
Steps	Strip configured response headers → apply topology hiding (mask internal producer addresses) → apply response-phase transformation rules	Apply response-phase transformation rules to the answer
Failure semantics	A response-rewrite error returns `502` to the consumer; the retry path logs and continues	Errors are logged and the answer is still sent

Hot reload

Each chain is immutable once built. When a config or control-plane-store change lands, the proxy builds fresh request and response chains and swaps them in atomically. The SBI proxy and the Diameter relay both pick up the new chains without dropping in-flight requests, so policy stays consistent across protocols. See Hot reload and runtime ops.

Where to go next

Policy engine — first-match-wins evaluation.
Transformation engine — request and response phases.
Routing engine — what runs after the chain allows.