Move one representative workload first. RedRouter implements specific OpenAI-style and Anthropic-style inference surfaces; compatibility does not imply that every endpoint, field, hosted tool, or model behavior transfers unchanged.
Choose the matching API
| Existing workload | RedRouter endpoint | Migration focus |
|---|---|---|
| OpenAI Chat Completions | POST /v1/chat/completions | Base URL, RedRouter model ID, accepted fields, stream and usage parsing |
| OpenAI Responses | POST /v1/responses | Stateless history replay, supported input items, client-executed tools |
| Anthropic Messages | POST /v1/messages | RedRouter model ID, required output limit, content blocks and error envelope |
Create a funded account and an API key. Trial credit is for Chat; it does not enable API generations. Replace the original service's key with your RedRouter key and choose an exact model ID from Models.
For an OpenAI-compatible client, set its base URL to https://redrouter.org/v1 and send the RedRouter key as Bearer authentication. For an Anthropic-compatible client, configure its origin so it sends to https://redrouter.org/v1/messages; Messages accepts x-api-key as well as Bearer authentication. Check the final URL in your client configuration to avoid a duplicated /v1 segment.
Use the Python, Node.js, or Integrations guide for client-specific setup. The compatibility guide defines supported behavior; a familiar request shape is not a promise of identical model output.
Migrate Chat Completions
Start with a short model, messages, and max_tokens request. Remove service-specific extensions and add optional fields back only when both the endpoint and selected model support them. Unknown or unsupported fields can return 400 rather than being silently forwarded.
Preserve your full conversation and tool-result history. RedRouter returns tool calls for your application to execute; it does not run your functions. Validate complete arguments, enforce your own permissions, and return tool results using the documented roles and call IDs. See Chat Completions and Tool calling.
For streaming, assemble deltas by their indexes and read through the terminal sequence. Request terminal usage with stream_options: {"include_usage": true} when your client supports it. Do not require usage to be present to accept an otherwise complete answer, and do not interpret missing usage as zero.
Migrate Responses
RedRouter's Responses surface is stateless. Send the complete history on every turn, including prior tool calls and their matching results. Replace flows based on previous_response_id, server conversations, or retrieving a stored response with history that your application owns.
The store field is accepted but the response always reports false. It does not control request-content retention. Hosted tools and file resources are outside this compatibility surface; client-executed function and freeform tools are supported within the documented translation.
Some fields are accepted as compatibility hints or ignored. Before relying on reasoning controls, output formatting, truncation, or tool strictness, read Responses, Reasoning, and Structured output. Do not assume acceptance means the selected model enforces a field.
Migrate Messages
Send a RedRouter catalog model ID and a positive max_tokens. Preserve the Messages layout: top-level system, user and assistant messages, assistant tool_use, and user tool_result blocks. Your application still executes tools.
Read the Messages-specific error body rather than an OpenAI error shape. Insufficient credit returns 403, and most RedRouter diagnostic codes are not included in its JSON body. Streaming uses named events and ends with message_stop; parse the event type as well as its data. See Messages and Errors.
Input features, thinking controls, caching hints, images, and structured output depend on the compatibility translator and chosen model. Review Compatibility and send a minimal request before restoring all your client's defaults. Use Token counting as an estimate, not tokenizer-exact proof of context fit.
Recheck application assumptions
- Choose a model deliberately and evaluate its answers on your real task. RedRouter does not automatically substitute another model.
- Keep local validation for JSON schemas and tool arguments. A successful HTTP request does not establish application correctness.
- Review SDK retry defaults. A local timeout or partial stream can leave an uncertain original request; a retry creates another possible charge.
- Set realistic output limits, enough credit for concurrent holds, and account-wide backpressure.
- Set retention explicitly for each key or use account Zero Data Retention before sending sensitive content.
Validate the cutover
Compare a small set of representative prompts for quality, completion behavior, tool correctness, latency, and actual reported cost. Include a multi-turn exchange, streaming completion, tool round trip if used, and a deliberate unsupported-field error. Exercise retry and disconnect handling with local fixtures.
Switch traffic gradually using your application's own configuration. Keep model changes visible in your records so outputs can be compared correctly. If your application supports switching back, make that an explicit decision with your own retention and budget implications. Use Production use for dispatch, retries, and diagnostics before expanding traffic.