Most blog posts about API gateways assume REST is the only protocol that matters. In the regulated platforms we work with most — banks, ministries, telcos — that assumption is wrong by an entire decade.
A typical bank has core systems exposed over SOAP/WSDL written in 2008, new microservices exposed over gRPC, a mobile backend exposed over GraphQL, and a partner integration layer exposed over REST. All four have to be governed. All four have to be audited. All four have to ride on the same identity, the same rate limits, the same observability.
The interesting question is what changes when you put them on one policy pipeline.
What "one policy pipeline" actually means
A protocol-aware gateway doesn't translate everything to REST. That's the lossy version. A real multi-protocol gateway accepts each protocol on its native terms, normalizes the parts that need normalizing, runs the same policies, and emits the same audit shape.
The pipeline runs in five phases, identical regardless of protocol:
[ pre-flow ] → [ conditional ] → [ routing ] → [ post-flow ] → [ fault-handler ]
Pre-flow policies fire before routing — authentication, identity resolution, rate limit, payload validation. Conditional policies fire when their predicates match. Routing decides the upstream. Post-flow fires after the upstream call — response transformation, audit, observability emission. Fault-handler fires when anything in the preceding phases raises.
The phase model is the same. The implementations within each phase are protocol-aware.
What's protocol-specific and what isn't
Authentication is mostly the same. OAuth2, OIDC, JWT, API keys, mTLS — all of these are protocol-agnostic. The bearer token might arrive in an HTTP header for REST, a SOAP header for WSDL, or gRPC metadata for gRPC — the auth policy reads from the right place and emits the same identity object.
Rate limiting is the same. A request is a request. The rate-limit policy doesn't care whether the request shape was SOAP or GraphQL — it counts it against the consumer's window.
Audit is the same shape. Actor, timestamp, endpoint, upstream, response code, latency, payload digest. The same Elasticsearch index holds REST and SOAP audit records side by side. Auditors don't have to learn two trails.
Validation is protocol-specific. WSDL validation runs against XSD. OpenAPI validation runs against the JSON schema. GraphQL validation runs against the schema document. Each protocol gets a validator that understands its own semantics — but the validator runs in the same phase as every other validator.
Transformation is protocol-specific. SOAP-to-SOAP envelope changes, REST-to-REST field projections, GraphQL response shaping — each protocol's transforms live alongside protocol-agnostic ones (PII sanitization, header rewrites, redaction).
SOAP — the protocol nobody admits they still need
Every "modern API platform" pitch quietly skips SOAP. Every bank still runs SOAP. Every ministry still runs SOAP. The mismatch is funny until you have to operate the platform.
A multi-protocol gateway handles SOAP as a first-class proxy type — not "translate to REST and back," which mangles WSDL semantics — but native WSDL ingestion, native XSD validation, native WS-Security where the upstream requires it.
Practical implications:
- One-click proxy from a WSDL. Drop the WSDL on the Manager; get a policy pipeline-wrapped SOAP proxy with the same auth, audit, and rate-limit options as a REST proxy. No custom code.
- WS-Security is supported, not translated. Some upstreams require WS-Security headers (UsernameToken, X.509, timestamp). The gateway produces them; the proxy stays valid.
- Faults are first-class. A SOAP Fault doesn't become a 502 with a buried payload — it stays a Fault, gets audited as a Fault, and reaches the consumer in the shape the consumer expects.
We've watched banks decommission third-party SOAP gateways once they got their SOAP traffic onto the same pipeline as their REST traffic. The "one platform" story is the load-bearing one — the regulator doesn't want two audit trails.
gRPC — what changes when streaming arrives
gRPC adds two things REST doesn't have: bidirectional streaming and binary protobuf payloads. Both have to be handled without forcing the pipeline into a request-response shape.
Streaming. A unary gRPC call looks like REST. A server-streaming or bidirectional-streaming call looks nothing like REST — there's no single "response body" to transform. The gateway has to forward the stream, applying policies on the metadata and on each message individually if the policy says so.
Protobuf payloads. Some policies need to read the payload — for example, a redaction policy. Those policies have to understand protobuf, or they have to declare themselves "header-only" and skip payload inspection. We mark policies explicitly: payload-aware or metadata-only.
Reflection-driven proxy creation. Instead of asking a team to hand-write proxy specs for each gRPC service, the gateway can use the service reflection to generate proxies automatically. The auth, audit, and rate-limit policies still attach by default — the team gets a governed gRPC service without writing config.
GraphQL — when "one endpoint" is the problem
GraphQL is the opposite shape of REST. REST has many endpoints; the gateway routes per-endpoint. GraphQL has one endpoint and many operations; the gateway has to route per-operation if it wants to apply meaningful policy.
The way this works in practice:
- Operation-level policy. The gateway parses the GraphQL document, identifies the operation (query / mutation / subscription) and the named operation, and applies per-operation policy. A read-only query gets one rate-limit class; a heavy mutation gets another.
- Schema-aware redaction. PII fields can be marked at the schema level; the gateway redacts them on the way out without needing the application to know.
- Depth and complexity limits. Default to enforcing depth and complexity caps. A GraphQL endpoint without these limits is a denial- of-service waiting to happen.
- Subscription handling. Subscriptions are streams. Same rules as gRPC streaming — metadata is governed; payload-aware policies have to declare themselves.
What customers actually do with this
The interesting cases are the ones where multiple protocols share policy.
Identity federation across all four. A consumer issued a JWT through Identity Manager can call REST endpoints, SOAP endpoints, gRPC services, and GraphQL operations — same token, same identity. The audit shows one consumer, one identity, four protocols.
Rate limiting at the consumer, not the endpoint. A partner with a contract for "10,000 calls per hour" doesn't care about the protocol distribution. The gateway applies the limit at the consumer; the mix of REST and SOAP and gRPC inside that limit is the partner's choice.
Cross-protocol audit. A regulator asks "what did this consumer do between these dates." One Elasticsearch query returns every call across every protocol — same shape, same fields. Auditors don't have to learn four trails.
Protocol migration as a soft transition. A bank wants to move a SOAP service to gRPC. The gateway can expose both: same backend, two proxies, same policy. Consumers migrate at their pace. Audit captures both paths.
# Two proxies, same backend, different protocols — APIops
proxies:
- name: payments-soap
type: soap
spec: ./payments.wsdl
policies: [auth, rate-limit, audit]
- name: payments-grpc
type: grpc
spec: ./payments.proto
policies: [auth, rate-limit, audit]
What multi-protocol doesn't fix
Three things teams sometimes expect from a multi-protocol gateway that the gateway can't actually do:
Make a bad API design good. If the SOAP service is poorly designed, putting it behind the gateway doesn't fix it. The gateway governs traffic; it doesn't refactor the upstream.
Translate semantics. SOAP-to-REST translation works mechanically for simple cases and breaks for anything interesting (WS-* extensions, attachments, headers carrying state). Don't try to translate SOAP into REST and expect lossless behavior. Govern SOAP as SOAP.
Remove the need for upstream understanding. The team operating the gateway still needs to understand what the upstream protocols do. Protocol-awareness in the gateway means the operator can govern; it doesn't mean the operator can skip learning.
What we measure
Across multi-protocol platforms, four numbers tell you whether the gateway is doing its job:
- Per-protocol latency overhead. The gateway should add tens of milliseconds, not hundreds. Watch the p99.
- Audit completeness across protocols. Same percentage of audit emissions for REST, SOAP, gRPC, GraphQL. If one is lagging, a phase is misconfigured.
- Cross-protocol identity propagation. A consumer's JWT should resolve the same identity across all four. Mismatch indicates a policy gap.
- Streaming throughput. For gRPC and GraphQL subscriptions, the gateway should pass through streams without buffering them. Watch the throughput per consumer.
These are observable on the same Analytics Engine the platform team already has open.
Why this matters
The bank, ministry, and telco scenarios aren't going away. SOAP isn't going away — billions of dollars in business processes ride on it. gRPC and GraphQL are growing. New protocols (HTTP/3, server-sent events, MQTT for IoT, MCP for AI) keep showing up. The gateway that treats one protocol as native and the rest as awkward stepchildren is the gateway that gets bypassed.
The gateway that runs every protocol on the same pipeline becomes the default place to govern API traffic. The audit trail gets unified. The identity model gets unified. The operations team learns one platform instead of four.
If you're running multiple protocols today through multiple gateways, the consolidation conversation is worth having. The team can walk through what migration looks like on your cluster in 30 minutes.