VoyageAge

OpenRouter Migration Guide

Migrate from OpenRouter to VoyageAge

If your application already uses the OpenAI SDK or an OpenAI-compatible request format with OpenRouter, this migration-focused walkthrough covers the API key, base URL, model ID, and OpenRouter-specific configuration. Use the VoyageAge documentation for complete API setup and endpoint reference.

Get VoyageAge API Key Compare with OpenRouter
Migration diffOpenRouter → VoyageAge
API keyOPENROUTER_API_KEYVOYAGEAGE_API_KEY
Base URLopenrouter.ai/api/v1api.voyageage.com/v1
Model IDOpenRouter slugVoyageAge model ID
HeadersAttribution headersReview / remove
RoutingProvider preferencesReview separately
Review before production5 configuration areas

Fast path

OpenRouter Migration in a Few Steps

Start with a temporary development configuration. Move production traffic only after the new endpoint behaves as expected.

  1. 01

    Create a VoyageAge API key

    Use a separate key for migration testing and rollout.

  2. 02

    Replace the OpenRouter key

    Load the VoyageAge key from VOYAGEAGE_API_KEY.

  3. 03

    Change the base URL

    Point the OpenAI client to https://api.voyageage.com/v1.

  4. 04

    Confirm the model ID

    Choose an exact current ID returned by https://api.voyageage.com/v1/models.

  5. 05

    Review OpenRouter-only settings

    Remove attribution headers and inspect routing or fallback options.

  6. 06

    Run a small test request

    Verify the response before changing production traffic.

  7. 07

    Confirm VoyageAge usage

    Check the selected model and matching request in VoyageAge Console.

Before and after

Change the OpenAI Client Configuration

Keep the OpenAI Python client, then replace the provider-specific connection values. The example model is sourced from VoyageAge's shared documentation configuration.

Before

OpenRouter

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key=os.environ["OPENROUTER_API_KEY"],
)

response = client.chat.completions.create(
    model="OPENROUTER_MODEL_ID",
    messages=[{"role": "user", "content": "Hello"}],
)
https://openrouter.ai/api/v1
After

VoyageAge

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://api.voyageage.com/v1",
    api_key=os.environ["VOYAGEAGE_API_KEY"],
)

response = client.chat.completions.create(
    model="gpt-5.6-sol",
    messages=[{"role": "user", "content": "Hello"}],
)
https://api.voyageage.com/v1

VoyageAge endpoint and example model values come from the same documentationConfig used by the current product docs. OpenRouter's base URL and optional attribution headers were checked against its current official Quickstart.

Migration scope

What Changes and What Can Often Stay the Same

OpenAI-compatible does not mean every provider-specific behavior is interchangeable. Separate the standard request flow from OpenRouter-only configuration.

What usually changes

  • API key and environment variable
  • OpenAI client base_url
  • Model ID or alias
  • OpenRouter attribution headers
  • Provider routing, fallback, or preset settings

What can often stay the same

  • OpenAI SDK client in many integrations
  • Standard messages array and roles
  • Much of the surrounding application logic
  • Streaming and tool-call flow after model-specific testing

Keep these only after confirming the selected VoyageAge model supports the workflow your application needs.

Catalog check

Check Your Model IDs

OpenRouter model slugs and VoyageAge model IDs are not guaranteed to match. Do not copy a provider-prefixed or alias-based OpenRouter model name into the new configuration without checking it.

  1. Request the current VoyageAge model list.
  2. Select the exact ID available to your account.
  3. Update application and environment configuration.
  4. Test that model before moving traffic.
Model discoveryhttps://api.voyageage.com/v1/models

Request cleanup

Review OpenRouter-Specific Headers

OpenRouter currently documents optional attribution headers. They are specific to OpenRouter's rankings and analytics workflow and are not required for a standard VoyageAge request.

HTTP-RefererX-OpenRouter-TitleX-OpenRouter-Categories

Remove or review them deliberately instead of forwarding provider-specific metadata by habit. OpenRouter still supports X-Title for backward compatibility, but its current documented name is X-OpenRouter-Title.

Provider behavior

Review Routing and Fallback Settings Separately

OpenRouter supports provider ordering, fallback controls, routing preferences, multiple-model fallbacks, and presets. Those settings belong to OpenRouter's routing layer.

OpenRouter requestprovider.orderallow_fallbacksmodels[]@preset/…
Migration actionReview separately

Do not copy provider routing or fallback configuration unchanged unless VoyageAge documentation explicitly describes an equivalent.

Model-specific validation

Verify Streaming and Tool Calls

If your application relies on streaming or tool calls, test those workflows with the specific VoyageAge model you plan to use before moving production traffic. Similar request shapes do not guarantee identical model behavior.

  • Test one streamed response from start to finish.
  • Test each tool schema and result round trip.
  • Confirm error handling and cancellation behavior.

Safe rollout

Move Production Traffic Gradually

  1. 01Test locally
  2. 02Validate staging
  3. 03Move a limited workload
  4. 04Review usage and errors
  5. 05Complete the migration

Pre-flight review

OpenRouter Migration Checklist

Use this list before directing meaningful production traffic to the new provider.

  • VoyageAge API key loaded
  • Base URL replaced
  • Model IDs checked against /v1/models
  • OpenRouter headers removed or reviewed
  • Routing-specific configuration reviewed
  • Normal request tested
  • Streaming tested if used
  • Tool calls tested if used
  • Usage visible in VoyageAge
  • Production traffic migrated gradually

Connection check

How to Verify the Migration

Keep the old credential available until the replacement path has passed a controlled test.

View VoyageAge Docs
  1. 1

    Send a small non-production request through the VoyageAge base URL.

  2. 2

    Confirm the selected model returns a normal response.

  3. 3

    Check VoyageAge Console for a matching usage record.

  4. 4

    Verify the recorded model matches the intended model ID.

  5. 5

    Test streaming and tool calls separately if the application uses them.

  6. 6

    Remove old OpenRouter credentials only after the new path is validated.

Migration problems

Troubleshoot the Most Common Switch Issues

Check the new credential, base URL, and model ID before changing application logic.

401 Unauthorized

Confirm the new request reads VOYAGEAGE_API_KEY, the key is active, and no copied whitespace is present.

404 Endpoint Not Found

Use https://api.voyageage.com/v1 as the OpenAI client base URL. Do not append /chat/completions twice.

Model not found

Do not assume an OpenRouter model slug is reusable. Request https://api.voyageage.com/v1/models and copy an exact current VoyageAge ID.

Request still goes to OpenRouter

Inspect environment variables, deployment secrets, client construction, and cached configuration for the previous base URL.

Streaming behavior changed

Run a streamed request against the exact target model and verify chunk handling, termination, errors, and cancellation.

Tool call failed

Confirm the selected model supports the required tool workflow and validate the tool schema and result messages against the current request format.

Open the complete API reference

Commercial context

Why Move an Existing API Workload?

01

Lower API Cost

Evaluate VoyageAge pricing for the supported models your workload already uses.

02

OpenAI-Compatible Workflow

Keep a familiar SDK pattern while changing provider connection values.

03

Supported GPT and Claude Models

Use one VoyageAge account for supported OpenAI and Claude model families.

Want the full product and pricing comparison? Compare VoyageAge with OpenRouter.

Learn how the broader VoyageAge OpenAI-compatible API works. Using a developer agent instead? See the Claude Code custom API guide or Codex custom API guide.

Quick answers

OpenRouter Migration FAQ

01

How do I migrate from OpenRouter to VoyageAge?

Create a VoyageAge key, update the OpenAI client base URL, choose a current VoyageAge model ID, review OpenRouter-specific settings, then test the replacement path before moving production traffic.

02

Can I keep using the OpenAI SDK after leaving OpenRouter?

Yes, for VoyageAge workflows supported through its OpenAI-compatible endpoint. Update the client connection values and verify the specific request features and model you rely on.

03

Do OpenRouter model IDs work with VoyageAge?

Do not assume they do. OpenRouter uses its own model slugs and aliases. Query the VoyageAge /v1/models endpoint and select an exact ID available to your key.

04

Do I need OpenRouter-specific headers with VoyageAge?

No for a standard VoyageAge request. OpenRouter attribution headers such as HTTP-Referer and X-OpenRouter-Title are specific to OpenRouter app attribution and should be reviewed or removed.

05

Can I migrate streaming and tool calls?

You can test those workflows through supported VoyageAge models, but validate each target model and request flow before moving production traffic. Do not assume behavior is identical across providers.

06

Should I remove my OpenRouter API key immediately?

No. Keep the old credential protected until the VoyageAge path passes local, staging, usage, and feature validation. Revoke the old key after the migration is complete.

Start with a controlled test

Ready to Move Your API Workload?

Create a VoyageAge API key, update a development configuration, and verify the new route before migrating production traffic.

Get VoyageAge API Key Compare VoyageAge with OpenRouter
Need help?Chat on Discord