API Overview
RouteAPI provides enterprise-oriented unified AI API access, aggregating model capabilities such as OpenAI, Claude, Gemini, Azure, and AWS Bedrock into a stable, observable, and measurable interface system. Business systems only need to connect to RouteAPI to call different model services with unified authentication, unified model IDs, and unified logs.
Supported protocol entries
Section titled “Supported protocol entries”RouteAPI supports three mainstream protocols: OpenAI-compatible, Claude Messages, and Google Gemini. You can keep using existing SDKs or clients and only switch the Base URL and API Key to RouteAPI.
| Protocol | Typical endpoints | Suitable scenarios |
|---|---|---|
| OpenAI compatible | /v1/chat/completions, /v1/responses, /v1/embeddings | OpenAI SDK, Cursor, OpenCode, LangChain, LiteLLM and other compatible clients |
| Claude Messages | /v1/messages | Claude Code, Anthropic SDK, Claude-native message clients |
| Google Gemini | /v1beta/models/{model}:generateContent | Google GenAI SDK, Gemini REST clients |
Requests entering through different protocols are adapted inside RouteAPI as needed. From the business side, choose the protocol natively supported by the current client first.
Base URLs
Section titled “Base URLs”OpenAI-compatible and Claude Messages protocols use by default:
https://www.routeapi.ai/v1Google Gemini protocol uses by default:
https://www.routeapi.ai/v1betaCommon request headers
Section titled “Common request headers”Authorization: Bearer sk-your-routeapi-tokenContent-Type: application/jsonAll protocols use the same type of RouteAPI Token. Store Tokens on the server side and do not expose them in browsers, mobile apps, or public repositories.
Protocol compatibility scope
Section titled “Protocol compatibility scope”RouteAPI tries to preserve the native calling experience of each protocol while forwarding requests to suitable model services. Actual support depends on model, service capability, and request parameters:
| Capability | Description |
|---|---|
| Chat Completions | Recommended basic chat API for most OpenAI SDK compatible clients |
| Responses | Suitable for clients and coding agents that support OpenAI Responses |
| Embeddings | Used for vector search, semantic search, and RAG |
| Streaming | Returns incremental content through SSE |
| Claude Messages | Supports Claude-native message structure, suitable for Claude Code and Anthropic SDK |
| Google Gemini | Supports Gemini generateContent style requests |
| Tool Calling | Depends on whether the model supports tool calling |
| Structured Outputs | Depends on whether the model supports JSON mode or JSON Schema |
| Vision / Multimodal | Depends on whether the model supports image or multimodal input |
API stability conventions
Section titled “API stability conventions”- Request parameters are preserved as much as possible and forwarded according to the protocol.
- Optional scalar parameters explicitly passed as
0orfalseshould be treated as explicit values, not dropped as defaults. - Parameters unsupported by different models may be adapted, ignored, or trigger errors, depending on model compatibility rules.
- In production, fix model IDs and prepare fallback strategies for key business flows.
- For optional capabilities such as tool calling, structured output, visual input, and streaming usage statistics, validate in a test environment before launch.
Enterprise integration recommendations
Section titled “Enterprise integration recommendations”- Encapsulate RouteAPI Tokens on the server side and avoid exposing keys directly to business frontends.
- Use different Tokens for different business systems to simplify independent limits, auditing, and troubleshooting.
- Fix model IDs and protocol paths; do not rely on temporary aliases or display names.
- Record request ID, model ID, status code, latency, and token usage to troubleshoot latency and cost anomalies.
- Enable streaming timeouts, failure retries, and alternative model options for core business flows to reduce the impact of a single model service issue.