Google API Gateway 開放串流支援 Public Preview，無須更改 API 規格

OCT. 22, 2026

For most of the last decade, an API call looked like a transaction. A client sent a request, waited, and got a complete response back in one piece. That model is exactly what most API management tooling — including API Gateway — was built to handle, and it still describes a huge amount of production traffic.

But that no longer describes all traffic types. A model generating a response emits tokens as it produces them, not in one batch at the end. An agent working through a multi-step task reports progress as it goes. A dashboard, a collaborative editor, a live inference endpoint — these all need a connection that stays open and carries data in both directions.

Until now, developers building those experiences in API Gateway had to make an uncomfortable choice: put API Gateway in front of their APIs and give up streaming, or route streaming endpoints around the gateway and give up the authentication, API key enforcement, and observability that made the gateway essential in the first place. Teams ended up with a split estate — governed APIs on one path, ungoverned streaming traffic on another.

We're announcing that streaming support in API Gateway is available in Public Preview. Your streaming endpoints can now sit behind the same gateway, with the same policies, as everything else you serve.

For AI applications, streaming also strengthens API Gateway's connection to Gemini platform. A gateway that uses model routing now streams responses from Gemini, Claude and OpenAI gpt-oss models in model garden in Gemini platform as they're generated, and streaming backends you host anywhere else work the same way. Alongside Apigee and Agent Gateway in Gemini platform, API Gateway is the lightweight entry point to Google Cloud's AI gateway capabilities.

What you can stream

API Gateway now supports the full range of streaming patterns modern APIs rely on:

Server-Sent Events (SSE) — the de facto standard for streaming model output to a browser or client SDK, and the transport behind most OpenAI-compatible chat completion APIs.
Chunked transfer encoding and HTTP response streaming — including newline-delimited JSON (NDJSON) and any other progressively-delivered response body. Responses are passed through as your backend produces them rather than buffered and delivered at the end.
WebSockets — full-duplex connections for chat, collaboration, live dashboards, notifications, and interactive sessions.
gRPC streaming — server-side streaming and bidirectional streaming, so you can put a gateway in front of gRPC services that were previously impossible to proxy.

Streams can stay open for up to one hour. As with any long-lived connection, clients should implement reconnection logic so that a session survives the end of a stream — a well-behaved WebSocket or SSE client should be doing this anyway.

Your API contract doesn't change

This is the part we are most pleased with: there is nothing new to learn.

Streaming is not a different product, a different resource type, or a different way of describing your API. There are no new extensions to add, no streaming-specific annotations, no separate spec for streaming operations. The same document that describes your existing API describes your streaming API.

Everything you already rely on continues to work exactly as before:

API key enforcement
JWT validation, including Firebase, Auth0, Okta, and Google ID tokens
Service account authentication to backends
Cloud Logging and Cloud Monitoring integration
Path templating and request routing

During Public Preview, you opt-in when creating the gateway:

gcloud api-gateway gateways create GATEWAY_ID \
  --api=API_ID \
  --api-config=CONFIG_ID \
  --location=REGION \
  --enable-streaming

Plain text

Copied

That single flag is the entire difference. At GA, it is planned that streaming will simply be how API Gateway behaves, with no opt-in required and, as during Preview, no changes to your API config.

A hostname you can predict

Alongside streaming, gateways get a deterministic default hostname:

GATEWAY_ID-PROJECT_NUMBER.REGION.gateway.dev

(Example: streaming-test-12345.us-central1.gateway.dev)

Plain text

Copied

Previously the default gateway.dev hostname included a generated hash, which meant you could not know your gateway's URL until after you had created it. That is a small thing that causes a lot of friction: you can't write the endpoint into a client config, a Terraform module, a CI pipeline, a firewall allowlist, or a partner integration doc until the resource exists — and if you tear the environment down and rebuild it, the URL changes underneath you.

Now the hostname is a pure function of values you already chose. You can generate it, template it, document it, and commit it to source control before the gateway exists, and you get the same URL every time you rebuild the same gateway in the same project and region. For anyone managing environments as code, or promoting a configuration from dev to staging to prod, this removes an entire category of bootstrapping problem.

Why this matters for AI workloads

Streaming isn't a niche feature for AI applications — it's the expected interaction pattern.

Users expect to see a model's response appear as it's generated, not after a thirty-second pause. Agents need to report intermediate steps. Tool-calling protocols and remote MCP servers depend on long-lived, incrementally-delivered connections. An API management layer that can't stream severely limits the user experience of AI applications.

With streaming, API Gateway becomes a viable front door for that agentic traffic — and the value of a front door is exactly the same as it's always been, only more urgent. AI endpoints are expensive, they consume quota, they need per-consumer authentication and rate limiting, and they need to be observable. These are the governance problems that an AI gateway is intended to solve. The alternative — every team standing up its own proxy in front of its own model endpoint — is how organizations end up unable to answer basic questions about who is calling what.

Model routing in API Gateway lets you expose a single OpenAI-compatible endpoint and dispatch requests to Gemini, Claude, or OpenAI gpt-oss models based on the model field in the request payload. Model routing plus streaming means clients get a familiar, standards-based streaming interface, while you retain centralized control over which models are reachable, by whom, and under what policy.

Streaming, model routing and MCP support are all features within API Gateway that provide a lightweight on-ramp to AI gateway capabilities within Google Cloud. These AI gateway capabilities allow teams to monitor, secure and control agentic traffic of tools, models and agents in their ecosystem, and they're delivered as a composable suite so you can choose the right gateway for each use case. For more expansive AI policies and full lifecycle management, use Apigee. To manage and secure agent connectivity, use Agent Gateway in Gemini platform. You can also combine these gateways: API Gateway or Apigee can sit in front of your agents and APIs, or behind Agent Gateway so your agents can reach models, tools, and MCP servers. For example, you can route your agent's egress through Agent Gateway for strict security governance, and then pass the request to API Gateway to handle model routing.

What to know during Public Preview

A few things to plan around while the feature is in Preview:

Streaming is enabled at gateway creation time. Existing gateways can't be converted in place; create a new gateway with the flag to try it.
A few API Gateway features are not available at the initial Preview launch, but will be coming during the Preview time period.
- Custom domains via Serverless NEGs and an external Application Load Balancer
- Streaming enablement via the Cloud console
- Terraform
Latency metrics reflect stream duration. Request latency for a streaming connection measures the life of the stream, not time-to-first-byte, so expect long-lived connections to change the shape of your latency graphs.

Get started

If you're already using API Gateway, the fastest way to see this working is to point a new streaming-enabled gateway at an existing backend that emits SSE and watch the events arrive incrementally. No spec changes needed.