Michael JohnsonA streaming backend keeps a connection open and sends data in chunks: SSE, for example, can send a model’s response text as it is generated, while WebSockets enable two-way communication. On October 22, 2026, Google announced a public preview of streaming in Cloud API Gateway. The gateway can pass through these responses and apply familiar authentication rules and observability tools to requests; testing requires creating a new gateway with streaming enabled.
Google’s announcement lists SSE, HTTP response streaming and chunked transfer encoding, WebSockets, and server-side and bidirectional gRPC streaming. HTTP responses are sent to the client as they arrive from the backend, including NDJSON. This lets teams keep streaming routes behind the same API Gateway that already handles standard requests.
What changes in the API and infrastructure
Streaming operations do not require a separate API description or special extensions to the specification. In the preview, streaming is enabled when creating a gateway with the --enable-streaming flag. Google says API key and JWT checks, backend authentication through a service account, routing, and integration with Cloud Logging and Cloud Monitoring are retained.
The preview also introduces a predictable hostname based on the gateway ID, project number, and region. For example, the address format is GATEWAY_ID-PROJECT_NUMBER.REGION.gateway.dev. You can insert it in advance into client or CI configuration. Recreating a gateway with the same ID, project, and region preserves that address.
Test without switching production traffic
- Choose an existing backend. Start with an endpoint that already sends SSE or a streaming HTTP response. This helps isolate gateway behavior from application changes.
- Create a separate gateway. Streaming is enabled at creation; you cannot change the mode of an existing gateway. Use a test ID and an appropriate region.
- Configure the backend deadline. For SSE and HTTP streaming, the default request deadline is 15 seconds; the stream closes when the configured deadline expires. In the OpenAPI configuration, set a
deadlinefor the backend that suits your use case: for a streaming gateway, the documentation allows a value of up to 3600 seconds. Also account for the backend’s own timeout—for example, Cloud Run may close the connection sooner. - Check the backend protocol. gRPC requires HTTP/2 (
h2), while WebSockets require HTTP/1.1. SSE and HTTP streaming work with HTTP/1.1 or HTTP/2; Google recommends HTTP/2 for these scenarios. - Check that data arrives. Confirm that the client receives initial events before the full response is complete. For WebSockets, test communication in both directions and plan for clients to reconnect after a connection ends.
- Review policies and metrics. Check authentication, logs, and request limits on the streaming route. The request latency metric reflects the full duration of the stream, so measure time to first event and intervals between events separately on the client.
For WebSockets and gRPC, the documentation sets a default 300-second interval without messages; for WebSockets, a timeout below 300 seconds does not apply, and the connection ends no later than 3600 seconds in any case. SSE and HTTP streaming use the configured wall-clock deadline. Consequently, a long request latency graph does not by itself show how quickly a user saw the first chunk.
Public preview limitations
At launch, streaming cannot be enabled through the Cloud Console or Terraform. Gateways with streaming enabled are also incompatible with HTTP(S) Load Balancing and Serverless NEG, so custom domains that depend on this setup are unavailable. Google lists these capabilities as future additions during the preview. Before planning production routing and automation, consult the streaming configuration documentation.
A practical first step is to point a new gateway at an existing streaming backend, set an explicit deadline, and compare a direct connection with the route through the gateway. This lets the team test protocol compatibility, authentication, and actual time to first event without changing the API contract or production traffic.