One API Does Not Mean One Protocol: Chat Completions, Responses, Messages, and Gemini

"OpenAI compatible" is useful shorthand, but it is not a complete integration contract. Two clients can accept the same API key and base domain while sending different request paths, authentication headers, payload shapes, streaming events, and tool-call formats. That difference matters when you connect coding agents, SDKs, or production applications to a multi-model gateway. At XiuAI, we expose four text-generation routes through XiuRouter: OpenAI Chat Completions OpenAI Responses Anthropic Messages Gemini GenerateContent The practical rule is simple: Start with the protocol your client actually sends. Do not choose a protocol from the model name or from an "OpenAI compatible" label. This article explains how to make that choice and how to verify the integration without turning a small configuration change into a production incident. A model name does not determine the request protocol. For example, the same model may be reachable through Chat Completions in one service group but not through Responses or Messages in another. A successful Chat Completions request is not proof that the same model and route will support Responses, Anthropic Messages, or Gemini GenerateContent. Use the client's native behavior as the starting point: Client or application Preferred route Codex, agents, and new OpenAI-style applications OpenAI Responses Claude Code, Anthropic SDKs, and Claude-native clients Anthropic Messages Existing OpenAI-compatible applications that do not support Responses Chat Completions Gemini SDKs and Gemini-native clients Gemini GenerateContent If the client documentation is unclear, inspect its official configuration guide or request logs. Do not infer the protocol from a generic compatibility badge. An OpenAI-compatible SDK usually appends paths under /v1\, so its configured base URL is: \text \ A Claude client that appends /v1/messages\, or a Gemini client that appends /v1beta/models/...\, should use the API root: \text \ This is a common source of duplicated paths such as /v1/v1/messages\, especially when a configuration field is called "API URL" without explaining whether it expects a domain, a base path, or a complete endpoint. For direct requests, use the complete path: Protocol Method and path Chat Completions POST /v1/chat/completions\ Responses POST /v1/responses\ Anthropic Messages POST /v1/messages\ Gemini GenerateContent POST /v1beta/models/{model}:generateContent\ OpenAI-compatible requests use a Bearer token: \http \ Anthropic Messages can use: \http \ XiuRouter also accepts a Bearer token on the Messages route for gateway clients such as Claude Code. Gemini GenerateContent can use: \http \ Gemini's key\ query parameter is accepted as well, but headers are easier to keep out of access logs and copied URLs. Before moving application traffic, test the exact combination of: API key model ID service group protocol streaming mode tool or structured-output features you need First list the models visible to the scoped key: \bash \ Then send one small request through the route your client will use. For Responses: \bash \ For Anthropic Messages: \bash \ After the response, verify the same request in usage records: key, model, service group, endpoint, token counts, status, and cost. The small test is billable. Check the current model and service-group pricing before sending it. A gateway route can support the core text request without implementing every provider feature. Current XiuRouter boundaries include: /v1/messages/count_tokens\ has no dedicated route. Claude Code documents token counting as optional and can fall back through inference, but you still need to verify that the final task completes. The Responses route is stateless. Stored conversations, previous_response_id\, background mode, and provider-hosted tools are outside the current compatibility scope. XiuRouter exposes Gemini GenerateContent, not the Gemini Interactions API. Files, fine-tuning, image variations, and some legacy endpoints are not implemented by the current gateway. Tool calls, structured output, prompt caching, streaming events, and token accounting can differ when an inbound request is converted to an upstream provider format. These are not edge cases to hide in fine print. They determine whether an agent can finish a task, whether a retry is safe, and whether usage records match the client's expectations. Create one key per application or environment. Limit models, service groups, quota, expiration, and IP scope where appropriate. For a migration: Keep the existing provider configuration available. Add XiuRouter as a separate provider or environment. Test a small non-critical task. Compare output, streaming, tool calls, token accounting, latency, and cost. Move traffic gradually. Keep the previous provider as the rollback path until the new route has passed real workloads. Changing only a base URL is convenient. Treating that change as proof of full protocol compatibility is not. The current endpoint table and limitations are maintained in the XiuRouter API compatibility guide. The guide was reviewed on August 22, 2026, and this article was checked against it on August 30, 2026. XiuAI and its products are operated by XiuLab Inc, a U.S. corporation.