> ## Documentation Index
> Fetch the complete documentation index at: https://docs.portix.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Protocol Translation: OpenAI Format Across All AI Providers

> Portrix automatically converts your OpenAI-format requests to each provider's native API format. No per-provider SDK needed — one protocol for all models.

Every AI provider has its own API format, authentication scheme, and request structure. Portrix bridges these differences so you write your integration code once and it works with all providers — no per-provider SDK, no per-provider request adapters, and no per-provider response parsers.

## The problem

The major AI providers have diverged significantly in their API designs.

**OpenAI** uses a `POST /v1/chat/completions` endpoint where messages are passed as an array of `{role, content}` objects. Tools are defined under a `tools` array with a `function` schema. Streaming responses are sent as `data: {...}` Server-Sent Events terminated by `data: [DONE]`.

**Anthropic** uses a `POST /v1/messages` endpoint with a different message shape — `system` is a top-level field rather than a message in the array, and content can be a structured list of blocks. Tools are defined differently, and its streaming format uses event types like `content_block_delta` rather than OpenAI's chunk format.

**Google Gemini** has its own REST API under `generativelanguage.googleapis.com` with entirely different field names (`contents` instead of `messages`, `parts` instead of `content`), a different authentication mechanism (API key as a query parameter), and its own streaming protocol.

Maintaining native integrations with each provider means writing and updating bespoke code for every API you consume.

## Portrix's solution

Portrix accepts all requests in the OpenAI format and translates them internally to each provider's native protocol before forwarding. The provider's response is also normalized back to OpenAI format before it reaches your application.

```
Your app (OpenAI format)
       │
       ▼
 Portrix Gateway
  ┌────────────────────────────┐
  │  Translate request format  │
  │  Add provider credentials  │
  │  Forward to provider       │
  └────────────────────────────┘
       │
       ▼
 AI Provider (native format)
       │
       ▼
 Portrix Gateway
  ┌────────────────────────────┐
  │  Normalize response        │
  │  to OpenAI format          │
  └────────────────────────────┘
       │
       ▼
Your app (OpenAI format)
```

Your code never changes — only the `model` field in your request determines which provider is used.

## Supported protocols

| Protocol                    | Description                                       | Notes                                 |
| --------------------------- | ------------------------------------------------- | ------------------------------------- |
| OpenAI Chat Completions     | `POST /v1/chat/completions` with `messages` array | Primary supported format              |
| OpenAI Completions (legacy) | `POST /v1/completions` with `prompt` string       | Supported for backward compatibility  |
| Embeddings                  | `POST /v1/embeddings` with `input` text or array  | Maps to each provider's embedding API |
| Tool / function calling     | Structured tool definitions and `tool_choice`     | Converted per-provider automatically  |
| Streaming (SSE)             | `stream: true` in the request body                | Normalized to OpenAI's SSE format     |

## Tool and function calling

When you define tools in OpenAI's function calling format, Portrix automatically converts those definitions to the equivalent format for the target provider. You write your tools once and they work across providers.

For example, the following tool definition works whether you target `openai/gpt-4o`, `anthropic/claude-3-5-sonnet`, or `google/gemini-1.5-pro`:

```python theme={null}
from openai import OpenAI

client = OpenAI(
    api_key="your-portrix-api-key",
    base_url="https://api.portrix.ai/v1",
)

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "Get the current weather for a location.",
            "parameters": {
                "type": "object",
                "properties": {
                    "location": {
                        "type": "string",
                        "description": "City and country, e.g. 'London, UK'",
                    }
                },
                "required": ["location"],
            },
        },
    }
]

response = client.chat.completions.create(
    model="anthropic/claude-3-5-sonnet",  # OpenAI tool format → Anthropic tools format
    messages=[{"role": "user", "content": "What's the weather in Tokyo?"}],
    tools=tools,
    tool_choice="auto",
)

print(response.choices[0].message)
```

Portrix translates the OpenAI `tools` schema into Anthropic's `tools` format (with `input_schema` instead of `parameters`) automatically, and maps the response back so `tool_calls` in the returned message follows the OpenAI shape.

## Streaming

Streaming responses via Server-Sent Events (SSE) are normalized to OpenAI's `data: {...}` format regardless of which provider processes the request. Enable streaming by setting `stream: true` in your request body.

```python theme={null}
from openai import OpenAI

client = OpenAI(
    api_key="your-portrix-api-key",
    base_url="https://api.portrix.ai/v1",
)

stream = client.chat.completions.create(
    model="google/gemini-2.0-flash",
    messages=[{"role": "user", "content": "Tell me a short story."}],
    stream=True,
)

for chunk in stream:
    delta = chunk.choices[0].delta.content
    if delta:
        print(delta, end="", flush=True)
```

Even though Google Gemini uses a different streaming protocol internally, the chunks you receive follow OpenAI's `ChatCompletionChunk` shape — so your streaming parsing code is portable across all providers.

<Note>
  Some advanced provider-specific features may not be available through the unified protocol layer. Features that have no equivalent in the OpenAI format — such as Anthropic's extended thinking tokens or provider-specific safety configurations — may require provider-specific headers or may not be accessible. Check the provider-specific documentation for edge cases.
</Note>