Skip to main content
Move your existing OpenRouter integration to NexLLM by updating your API endpoint, credentials, and model identifiers. NexLLM supports OpenAI-compatible Chat Completions, so you can keep your existing OpenAI SDK and standard message format.
The examples use documented NexLLM model identifiers. Before sending a request, confirm that the selected model is available to your API key through the Models endpoint.

Prerequisites

1

A NexLLM account with an active API key

Sign in to the NexLLM dashboard and create an API key.Review the key’s channel group, model restrictions, expiration, quota, and IP allowlist.See API Keys for setup instructions.
2

Available account balance

Check your account balance before testing billable requests.See Wallet for funding instructions.
3

An existing OpenRouter integration

This guide is for applications already using OpenRouter through the OpenAI SDK or an HTTP client.If you are starting a new integration, follow the Quickstart instead.

Quick Start for Claude Code Users

If you use Claude Code to edit your application, give it the following migration instructions. This is a prompt for updating your project, not a downloadable skill or a command that changes Claude Code’s own model provider.
Review the proposed changes before applying them.

Step 1: Update Your Environment Variables

Replace your OpenRouter configuration with NexLLM credentials and connection settings.
The examples below use these application environment variables.
Use a NexLLM-issued API key. Your OpenRouter credential is not a replacement for a NexLLM credential.Keep real keys in your server-side environment or secret manager. Never commit them or expose them in browser code.

Step 2: Update Your Client

Configure your client with the NexLLM base URL and API key.
For endpoint details, see Chat Completions.

Remove OpenRouter Attribution Headers

Remove OpenRouter-specific attribution headers from the NexLLM client:
  • HTTP-Referer
  • X-OpenRouter-Title
  • X-Title, if present in an older integration
Keep the authentication and content-type headers required by NexLLM. See Authentication.

Review Routing and Other Extensions

Do not forward OpenRouter-specific options without checking their replacement behavior. Review:
  • The provider object and provider preferences.
  • The models array used for model fallbacks.
  • Automatic model selection.
  • Plugins and request transformations.
  • Provider-specific privacy or retention controls.
Start your compatibility test with a minimal request, then add required features individually.
Channel groups are not a drop-in translation of OpenRouter’s request-level routing options.If your application relies on provider restrictions, fallback rules, regional processing, or privacy requirements, verify those requirements before moving the affected workload.

Step 3: Update Model Identifiers

Use the exact model IDs returned by NexLLM. Examples documented by NexLLM include: For example, an OpenRouter request using openai/gpt-4o should use NexLLM’s documented gpt-4o identifier, provided it is available to your key. Do not apply a blanket rule that removes or replaces every prefix. Some NexLLM identifiers contain a prefix, as shown by aws/claude-haiku-4-5.

List Models Available to Your Key

The returned catalog reflects your key’s channel group. Copy the desired id exactly. See the Models API.

Review Auto-Routing Separately

If your existing application uses openrouter/auto, do not automatically rename it to auto. Select an explicit NexLLM model for initial testing, and verify any automatic selection requirements separately.

Check Your Channel Group

Each NexLLM API key belongs to one channel group. That group determines model access and the pricing multiplier applied to usage. Before deployment:
  1. Check the group assigned to the production key.
  2. Confirm that it includes the intended models.
  3. Review its pricing and connectivity characteristics.
  4. Verify any additional key-level model restrictions.
See Channel Groups.

Step 4 (Optional): Adopt the Responses API

You can keep using Chat Completions after migrating. If your application needs the OpenAI Responses format, NexLLM also documents:
Before using this endpoint, check the selected model’s API compatibility in Model Square. The examples below assume NEXLLM_MODEL is set to a model that supports Responses.
Responses uses a different request and response shape from Chat Completions. Update your response parsing and test the specific features your application requires rather than changing only the endpoint.
See the API Reference for supported endpoint formats.

Why Migrate to NexLLM

Keep Your OpenAI-Compatible Client

Use NexLLM’s Chat Completions endpoint with your existing OpenAI SDK. For a basic integration, the main changes are the base URL, credential, and model ID. Review provider-specific extensions separately.

Access GPT, Claude, and Gemini

Use a single API integration for multiple model families, subject to your key’s permissions and channel group. Explore:

Choose Model Access and Pricing Through Channel Groups

Select a channel group that matches your model requirements and preferred pricing. The group ratio adjusts the model’s base usage cost:
Check current group availability and pricing before choosing a production configuration. See Channel Groups and Pricing.

Configure Access Controls Per Key

Create separate keys for different projects or environments. NexLLM documents configurable expiration, quota limits, model restrictions, and IP allowlists. See API Keys.

Review Requests and Usage

Use NexLLM’s usage logs to inspect request timing, key names, models, token consumption, and cost. The dashboard provides aggregate request, token, and quota statistics. See Usage & Logs.

Choose an API Format That Fits Your Application

Alongside Chat Completions, NexLLM documents Responses and Claude-native Messages endpoints. Check endpoint compatibility for your chosen model before changing formats. See the API Reference.

Troubleshooting

Call GET /v1/models using the same API key as the failing application.Verify the exact model ID, the key’s channel group, and any model restrictions configured on the key.Do not assume an OpenRouter identifier is accepted unchanged.See Models.
Confirm that NEXLLM_API_KEY contains your NexLLM credential, not the old OpenRouter key.Check for extra whitespace, stale deployment secrets, expiration, and IP allowlist restrictions.Standard OpenAI-compatible requests use:
See Authentication.
Confirm that the SDK base URL is:
Do not retain OpenRouter’s /api/v1 path or append /v1 twice.Test authentication and connectivity with:
A successful model-list request does not replace testing an actual completion request.
Review your account balance and the quota configured for the API key.Check both before retrying the request.See Wallet and API Keys.
Reduce the request to a supported model and a short messages array.Reintroduce optional fields one at a time, checking the chosen model’s endpoint compatibility.Pay particular attention to OpenRouter-specific routing fields, plugins, and fallback settings.Test streaming, tools, structured outputs, and multimodal inputs separately if your application uses them.
Check the requested model, actual token usage, and the pricing ratio for your key’s channel group.Review any applicable cache or multimodal charges.Use NexLLM’s pricing information rather than carrying over OpenRouter-specific accounting assumptions.See Pricing and Usage & Logs.

Verify Before Production

Use this checklist before completing the migration:
  • Replace the base URL and API key.
  • Confirm model IDs using the production key.
  • Review the key’s channel group and restrictions.
  • Remove OpenRouter attribution headers.
  • Review routing, fallbacks, and provider-specific fields.
  • Verify required privacy and retention controls.
  • Test representative prompts and conversation history.
  • Test streaming and other advanced features where used.
  • Check error handling, timeouts, and retries.
  • Review usage logs and expected costs.
  • Keep a tested rollback configuration during rollout.
Start with staging, then move a small portion of production traffic before expanding the rollout. Keep the old endpoint, credentials, model mapping, and request options together so rollback restores a consistent configuration.

Next Steps

API Reference

Explore supported endpoints and request formats.

Available Models

Find exact model IDs available to your API key.

Channel Groups

Understand model access and group pricing.

Usage & Logs

Inspect requests and monitor usage after migration.

Feedback

When reporting a migration issue to the NexLLM team, include:
  • Your SDK and version.
  • The endpoint and model ID.
  • The HTTP status and sanitized error message.
  • The approximate request time.
  • A request identifier, if available.
  • A minimal reproduction with sensitive content removed.
Do not include API keys, authorization headers, private prompts, or sensitive historical logs.