Skip to main content
Enterprise Feature
gRPC support is available on Enterprise self-hosted plans only. Contact the Portkey team to enable it for your gateway deployment.
gRPC support is currently in beta. The API surface may change based on feedback.
The Portkey Gateway supports gRPC as an alternative transport protocol alongside HTTP/REST. This enables lower latency, efficient binary serialization via Protocol Buffers, and native streaming support for applications that prefer gRPC communication.

How It Works

The gateway operates in two modes depending on the provider: For providers without a native gRPC endpoint, the gateway transparently proxies gRPC requests over HTTP — so every provider supported by Portkey works out of the box. When a provider does expose a native gRPC API (currently Google Gemini), the gateway connects directly for optimal performance.

Starting the gRPC Server

Command Line Flags

Environment Variables

Enabling TLS

The gRPC server supports TLS using the same certificates as the HTTP server:

Authentication

Pass your Portkey API key as gRPC metadata: With the Model Catalog, the provider is specified in the model string itself (@provider_slug/model_name), so separate provider headers are typically not needed.

Making Requests

All request bodies are sent as a JSON string in the input field of the GatewayRequest message. Each endpoint returns responses in a consistent format matching the API you called, regardless of the underlying provider:
  • ChatCompletions and Embeddings — OpenAI-compatible format
  • Messages — Anthropic Messages format
  • Responses — OpenAI Responses API format
The gateway handles all provider-to-format translation automatically — you always get the format matching the endpoint you called, no matter which LLM is behind it.

Model String Format

Portkey uses the Model Catalog format for model strings:
Examples: @openai/gpt-4o, @gemini/gemini-2.0-flash, @anthropic/claude-3-opus-20240229, @azure-openai/gpt-4

Chat Completions

Anthropic Messages

OpenAI Responses

Embeddings

Health Check

Native gRPC Providers

When a provider exposes a native gRPC API, the gateway bypasses HTTP entirely and makes direct gRPC calls for the lowest possible latency.

How Native gRPC Works

When a request targets a native gRPC provider, the gateway:
  1. Detects the gRPC transport via the x-portkey-gateway-transport: grpc header
  2. Transforms the request into the provider’s native gRPC format
  3. Makes a direct gRPC call to the provider’s endpoint
  4. Transforms the response back to the format matching the endpoint you called
This eliminates HTTP/JSON serialization overhead, uses efficient binary Protocol Buffer encoding, and maintains persistent gRPC connections with client caching.
The gateway handles all format transformations automatically — you send requests in the format matching the endpoint (Chat Completions, Messages, or Responses) and receive responses in that same format, regardless of the underlying provider.

gRPC Service Definition

The gateway exposes a single Gateway service with the following methods:

Message Types

Service Discovery

The gRPC server supports reflection, enabling service discovery with tools like grpcurl:

Response Format

The GatewayResponse contains an HTTP status code and a JSON body. The response format depends on which endpoint you called — the gateway ensures consistency regardless of the underlying provider.

ChatCompletions

Returns the standard OpenAI Chat Completions format:

Messages (Anthropic)

Returns the Anthropic Messages format — even when the underlying provider is not Anthropic (e.g., calling Messages with @openai/gpt-4o):

Responses (OpenAI Responses API)

Returns the OpenAI Responses API format:

Response Metadata

HTTP response headers are returned as gRPC trailing metadata:

Error Handling

Provider and request errors are returned inside the GatewayResponse.status_code field, not as gRPC status codes on the wire. The gRPC call itself will return OK unless there is a gateway infrastructure failure (e.g., server crash, proto parse error). Use the table below to interpret the status_code value in the response:
Always check GatewayResponse.status_code to detect errors — do not rely on the gRPC call status alone.
Error responses include details in the body:

When to Use gRPC vs HTTP

Connection Management

The gateway maintains a cache of gRPC client connections:
  • Connections are reused per API key for efficiency
  • Stale connections are automatically cleaned up
  • Default timeout: 60 seconds (300 seconds for streaming)

Limitations

The following limitations apply during the beta period:
  • WebSocket-based realtime endpoints (/v1/realtime) are not available via gRPC
  • File upload/download operations use HTTP proxy mode only
  • Batch operations use HTTP proxy mode only
  • Only server-side streaming is supported (no bidirectional streaming)

Troubleshooting

Connection Refused

Ensure the gRPC server is running with the --llm-grpc flag:

Authentication Errors

Verify your Portkey API key is correctly passed as gRPC metadata:

INVALID_ARGUMENT Errors

Check that your request JSON is valid and properly escaped in the input field. Ensure the model string follows the @provider_slug/model_name format.

Timeout Issues

For long-running requests, increase the client-side timeout:
Last modified on March 9, 2026