> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nexllm.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Vercel AI Gateway

### Migrate from Vercel AI Gateway to NexLLM: update clients, authentication, model IDs, routing configuration, and observability.

Move your Vercel AI Gateway integration to NexLLM while keeping your application's existing AI SDK, OpenAI-compatible, or Claude-native request format.

This guide separates the connection changes from the gateway-specific behavior you need to review before production rollout.

<Note>
  You can continue using the Vercel AI SDK and hosting your application on Vercel. This migration changes the inference gateway, not necessarily your application framework or deployment platform.
</Note>

## Migration Overview

| Integration | NexLLM configuration |
| - | - |
| OpenAI SDK | Set the base URL to `https://www.nexllm.ai/v1` and authenticate with a NexLLM key. |
| Vercel AI SDK | Create an explicit provider with `@ai-sdk/openai`; use `.chat()` for Chat Completions. |
| Chat Completions over HTTP | Send requests to `POST https://www.nexllm.ai/v1/chat/completions`. |
| Claude-native HTTP | Send requests to `POST https://www.nexllm.ai/v1/messages` with native authentication headers. |
| Responses API | Use `POST https://www.nexllm.ai/v1/responses` after verifying model compatibility. |
| Model selection | Use an exact model ID available to your NexLLM key. |
| Gateway-specific routing | Review and migrate the behavior separately; do not copy gateway options unchanged. |

See [API Reference](/api-reference/overview) and [Authentication](/api-reference/authentication).

## Prerequisites

<Steps>
  <Step title="Create a NexLLM API key">
    Create a dedicated key for the migration and store it in your application's server-side secrets.

    Review its expiration, quota, model restrictions, IP allowlist, and group.

    See [API Keys](/get-started/getting-your-api-keys).
  </Step>

  <Step title="Confirm model access and endpoint compatibility">
    List the models available to your key. Check the selected model's details for the endpoint and capabilities your application needs.

    See [Models API](/api-reference/models) and [Model Details](/channel-groups/pricing-overview).
  </Step>

  <Step title="Inventory your existing integration">
    Identify client initialization, gateway credentials, model strings, provider options, custom headers, response metadata, and telemetry.

    Include background jobs, server routes, scheduled tasks, and local scripts.
  </Step>

  <Step title="Prepare acceptance tests and rollback">
    Preserve your current configuration until the migrated integration passes representative tests. Define rollback criteria before changing production traffic.
  </Step>
</Steps>

## Quick Start for Claude Code Users

You can give Claude Code the following prompt from your repository.

This is a suggested migration prompt, not an installable NexLLM migration skill.

```text theme={null}
Migrate this project's Vercel AI Gateway integration to NexLLM.

Use https://docs.nexllm.ai/ as the source of truth for NexLLM API
details. Start with https://docs.nexllm.ai/llms.txt.

1. Find @ai-sdk/gateway, gateway model strings, AI_GATEWAY_API_KEY,
   VERCEL_OIDC_TOKEN used for inference, ai-gateway.vercel.sh,
   providerOptions.gateway, and gateway response metadata.
2. Inventory required routing, fallback, caching, privacy, BYOK,
   service-tier, reasoning, and observability behavior before editing.
3. Use NEXLLM_API_KEY for the migrated requests.
4. For OpenAI-compatible clients, use:
   https://www.nexllm.ai/v1
5. For AI SDK Chat Completions, create an explicit @ai-sdk/openai
   provider and use its .chat(modelId) method.
6. For Claude-native requests, target:
   https://www.nexllm.ai/v1/messages
   Follow NexLLM's native authentication documentation and check
   how the installed SDK joins its base URL and request path.
7. Discover exact model IDs using GET /v1/models.
8. Do not assume Vercel gateway options or another platform's
   routing fields have a NexLLM equivalent.
9. Add model-discovery and inference smoke tests.
10. Report unresolved behavior gaps and rollback instructions.

Do not print or commit secrets. Ask before making billable requests,
changing production configuration, or deleting old credentials.
```

<Warning>
  Migrating application API calls does not automatically configure Claude Code itself to use NexLLM. Treat the coding agent's connection settings as a separate integration.
</Warning>

## Step 1: Update Your Environment Variables

Replace the credential used by the migrated inference calls:

```bash theme={null}
# Before
export AI_GATEWAY_API_KEY="YOUR_VERCEL_GATEWAY_KEY"

# After
export NEXLLM_API_KEY="YOUR_NEXLLM_API_KEY"
```

For the examples below, choose a model available to your key:

```bash theme={null}
# Example only: confirm availability before running requests.
export NEXLLM_MODEL="gpt-4o"

# For Claude-native examples:
export NEXLLM_CLAUDE_MODEL="aws/claude-haiku-4-5"
```

`NEXLLM_MODEL` and `NEXLLM_CLAUDE_MODEL` are application configuration variables used in this guide, not special API parameters.

### Replace the Gateway Authentication Fallback

Change application logic such as:

```javascript theme={null}
// Before
const apiKey =
  process.env.AI_GATEWAY_API_KEY ||
  process.env.VERCEL_OIDC_TOKEN;
```

to:

```javascript theme={null}
// After
const apiKey = process.env.NEXLLM_API_KEY;

if (!apiKey) {
  throw new Error("NEXLLM_API_KEY is required");
}
```

Use the NexLLM key for NexLLM requests rather than forwarding a Vercel gateway key or OIDC token.

For OpenAI-compatible requests, authentication uses:

```text theme={null}
Authorization: Bearer YOUR_NEXLLM_API_KEY
```

See [Authentication](/api-reference/authentication).

<Warning>
  Do not remove `VERCEL_OIDC_TOKEN`, cloud credentials, or provider keys globally without checking their other uses. They may still be required by unrelated services or your rollback path.

  Keep NexLLM credentials server-side. Do not expose them through public environment variables or browser bundles.
</Warning>

Review the new key's configured expiration rather than assuming it never expires.

See [API Keys](/get-started/getting-your-api-keys).

## Step 2: Update Your Client

Choose the example that matches your current request format.

The examples use environment variables for model selection so that your application can use the exact ID verified in Step 5.

### Vercel AI SDK

Keep the AI SDK, but replace implicit gateway model resolution with an explicit NexLLM-backed provider.

Install a version of `@ai-sdk/openai` compatible with your project's `ai` package. Avoid combining the gateway migration with an unrelated SDK major-version upgrade.

```bash theme={null}
npm install @ai-sdk/openai
```

Before:

```javascript theme={null}
import { generateText } from "ai";

const { text } = await generateText({
  model: "openai/gpt-4o",
  prompt: "Write a short greeting.",
});
```

After:

```javascript theme={null}
import { createOpenAI } from "@ai-sdk/openai";
import { generateText } from "ai";

const apiKey = process.env.NEXLLM_API_KEY;
const modelId = process.env.NEXLLM_MODEL;

if (!apiKey || !modelId) {
  throw new Error("NEXLLM_API_KEY and NEXLLM_MODEL are required");
}

const nexllm = createOpenAI({
  baseURL: "https://www.nexllm.ai/v1",
  apiKey,
});

const { text } = await generateText({
  model: nexllm.chat(modelId),
  prompt: "Write a short greeting.",
});

console.log(text);
```

<Warning>
  Use `nexllm.chat(modelId)` when targeting Chat Completions.

  The OpenAI provider's default model factory can select the Responses API. Do not replace `.chat(modelId)` with `nexllm(modelId)` without deliberately reviewing the endpoint change.
</Warning>

Check the [AI SDK OpenAI provider documentation](https://ai-sdk.dev/providers/ai-sdk-providers/openai) for client-library behavior and NexLLM's [Chat Completions reference](/api-reference/chat-completions) for the gateway endpoint.

Search all call sites, including `streamText`, shared provider factories, and provider registries. Updating one client does not migrate independently configured clients.

### OpenAI SDK and HTTP Clients

For an existing OpenAI client, replace:

```text theme={null}
https://ai-gateway.vercel.sh/v1
```

with:

```text theme={null}
https://www.nexllm.ai/v1
```

Then update the key and model ID.

<Tabs>
  <Tab title="Python">
    ```python theme={null}
    import os
    from openai import OpenAI

    client = OpenAI(
        base_url="https://www.nexllm.ai/v1",
        api_key=os.environ["NEXLLM_API_KEY"],
    )

    response = client.chat.completions.create(
        model=os.environ["NEXLLM_MODEL"],
        messages=[
            {"role": "user", "content": "Write a short greeting."}
        ],
        max_tokens=64,
    )

    print(response.choices[0].message.content)
    ```
  </Tab>

  <Tab title="JavaScript">
    ```javascript theme={null}
    import OpenAI from "openai";

    const apiKey = process.env.NEXLLM_API_KEY;
    const model = process.env.NEXLLM_MODEL;

    if (!apiKey || !model) {
      throw new Error("NEXLLM_API_KEY and NEXLLM_MODEL are required");
    }

    const client = new OpenAI({
      baseURL: "https://www.nexllm.ai/v1",
      apiKey,
    });

    const response = await client.chat.completions.create({
      model,
      messages: [
        { role: "user", content: "Write a short greeting." },
      ],
      max_tokens: 64,
    });

    console.log(response.choices[0]?.message?.content);
    ```
  </Tab>

  <Tab title="cURL">
    ```bash theme={null}
    curl https://www.nexllm.ai/v1/chat/completions \
      -H "Authorization: Bearer $NEXLLM_API_KEY" \
      -H "Content-Type: application/json" \
      -d '{
        "model": "gpt-4o",
        "messages": [
          {"role": "user", "content": "Write a short greeting."}
        ],
        "max_tokens": 64
      }'
    ```

    Replace `gpt-4o` if your selected model differs.
  </Tab>
</Tabs>

See [Quickstart](/get-started/quickstart).

### Anthropic SDK and Claude-Native Requests

You do not need to convert a Claude-native integration to Chat Completions solely to use NexLLM.

NexLLM documents:

```text theme={null}
POST https://www.nexllm.ai/v1/messages
```

with these headers:

```text theme={null}
x-api-key: YOUR_NEXLLM_API_KEY
anthropic-version: 2023-06-01
Content-Type: application/json
```

See [Native Authentication](/api-reference/authentication).

<Tabs>
  <Tab title="Python — Anthropic SDK">
    ```python theme={null}
    import os
    from anthropic import Anthropic

    client = Anthropic(
        # The SDK appends /v1/messages.
        base_url="https://www.nexllm.ai",
        api_key=os.environ["NEXLLM_API_KEY"],
    )

    message = client.messages.create(
        model=os.environ["NEXLLM_CLAUDE_MODEL"],
        max_tokens=64,
        messages=[
            {"role": "user", "content": "Write a short greeting."}
        ],
    )

    for block in message.content:
        if block.type == "text":
            print(block.text)
    ```
  </Tab>

  <Tab title="cURL">
    ```bash theme={null}
    curl https://www.nexllm.ai/v1/messages \
      -H "x-api-key: $NEXLLM_API_KEY" \
      -H "anthropic-version: 2023-06-01" \
      -H "Content-Type: application/json" \
      -d '{
        "model": "aws/claude-haiku-4-5",
        "max_tokens": 64,
        "messages": [
          {"role": "user", "content": "Write a short greeting."}
        ]
      }'
    ```
  </Tab>
</Tabs>

<Warning>
  An SDK base URL and a complete HTTP endpoint are not interchangeable.

  The Anthropic SDK example uses `https://www.nexllm.ai` because its Messages method supplies `/v1/messages`. The OpenAI SDK examples use `https://www.nexllm.ai/v1`.

  Confirm that the final request path contains exactly one `/v1` segment.
</Warning>

Preserve your native content-block handling when keeping the Messages API. If you deliberately switch to Chat Completions, translate system instructions, tools, content blocks, streaming events, and response parsing separately.

## Step 3: Review Vercel-Specific Headers and Metadata

Remove gateway-specific configuration from the NexLLM client after deciding how to preserve any behavior that depended on it.

Do not indiscriminately delete application tracing headers or Vercel deployment configuration used elsewhere.

<AccordionGroup>
  <Accordion title="Request headers and authentication">
    | Existing configuration | NexLLM migration action |
    | - | - |
    | Vercel key or OIDC token in `Authorization` | Replace with the NexLLM key for OpenAI-compatible requests. |
    | `x-api-key` on Claude-native requests | Keep the native header, but replace its value with the NexLLM key. |
    | `anthropic-version` | Retain the documented version header for Claude-native requests. |
    | `http-referer` or `x-title`, if present | Remove assumptions that these populate NexLLM attribution. Preserve required app identity in your telemetry. |
    | Gateway-specific project or deployment attribution | Keep required deployment context in application logs; verify any server-side header handling separately. |

    See [Authentication](/api-reference/authentication).
  </Accordion>

  <Accordion title="Response metadata and headers">
    | Existing dependency | Migration action |
    | - | - |
    | `providerMetadata.gateway` | Refactor consumers rather than expecting the same metadata object from another provider adapter. |
    | Inline gateway cost fields | Review NexLLM Usage Logs for reported cost; update code that expects gateway-specific billing fields. |
    | Gateway request or trace IDs | Retain application correlation IDs and record the Chat Completions response `id`. |
    | Gateway rate-limit headers | Inspect actual NexLLM responses before retaining header-dependent scheduling logic. |
    | Provider selection metadata | Verify what your selected endpoint returns; do not assume an identical field or routing trace exists. |

    See [Chat Completions](/api-reference/chat-completions) and [Usage & Logs](/account/usage-logs-and-statistics).
  </Accordion>
</AccordionGroup>

## Step 4: Decompose Your Gateway Options

Review `providerOptions.gateway` and any related request fields before removing them.

A connection change alone does not establish equivalent routing, caching, privacy, or timeout behavior.

<Note>
  The table below describes migration actions, not guaranteed one-to-one API replacements.

  “Verify separately” means this guide does not establish an equivalent NexLLM control from the referenced documentation. It does not necessarily mean the capability is unavailable.
</Note>

| Existing option or behavior | Recommended migration action |
| - | - |
| `order` — provider preference or fallback order | Preserve the required policy in application logic or verify a suitable NexLLM configuration. |
| `only` — allowed providers | Confirm that the selected model and channel configuration satisfy the restriction before sending traffic. |
| `sort: "cost"` | Select models and channel groups using applicable pricing; do not assume automatic cost optimization. |
| `sort: "ttft"` | Benchmark first-token latency and implement your selection policy explicitly. |
| `sort: "tps"` | Benchmark output throughput separately from first-token latency. |
| `models` — model fallback chain | Maintain an explicit, tested fallback policy if required. |
| `byok` | Verify a supported credential arrangement before migration. Do not forward provider secrets as arbitrary request fields. |
| `providerTimeouts` | Configure client deadlines and review retry behavior. A client timeout is not equivalent to per-provider failover. |
| `caching: "auto"` | Revalidate cache behavior for the target model and request format. |
| `zeroDataRetention` | Verify retention requirements before moving affected traffic. Do not treat removing the flag as preserving the policy. |
| `disallowPromptTraining` | Obtain confirmation of the required data-use policy rather than assuming equivalence. |
| `reasoning` | Translate only controls documented for the target model and endpoint. |
| `serviceTier` | Verify tier support and parameter semantics before sending a replacement field. |

For NexLLM-specific access and pricing configuration, see [Channel Groups](/channel-groups/overview) and [Pricing](/channel-groups/pricing-overview).

### Use Channel Groups Deliberately

Each NexLLM key belongs to one channel group. The group controls model access and the pricing ratio applied to usage.

Treat this as a key-level configuration decision, not a direct replacement for every per-request routing rule.

If separate workloads need different configurations, consider dedicated keys and select the appropriate key in trusted server-side code.

See [Channel Groups](/channel-groups/overview).

### Preserve Required Constraints

Before migrating a request that has provider or privacy restrictions:

1. Record the original requirement.
2. Identify how it will be enforced after migration.
3. Add a test or operational check.
4. Keep the old route until the replacement is verified.

Do not silently relax provider allowlists, output schemas, or privacy constraints to make requests succeed.

<Warning>
  Do not copy `routing.model.fallbacks`, `routing.provider.fallbacks`, `routing.model.sort`, or `model: "auto"` from another gateway's migration guide unless NexLLM separately documents and supports that configuration for your use case.
</Warning>

### Test Fallbacks Without Duplicating Work

If your application implements fallback:

* Distinguish retryable failures from invalid requests or credentials.
* Limit attempts and overall elapsed time.
* Avoid restarting after partial streamed output without an explicit policy.
* Prevent duplicate tool execution.
* Record which model was attempted and which one produced the accepted result.

## Step 5: Update Model Identifiers

Retrieve the model IDs available to the key that will serve production traffic:

```bash theme={null}
curl https://www.nexllm.ai/v1/models \
  -H "Authorization: Bearer $NEXLLM_API_KEY"
```

Use the exact `data[].id` value in inference requests.

See [Models API](/api-reference/models).

### Example Model Mapping

These are candidates to verify, not unconditional replacements.

| Existing Vercel model string | NexLLM candidate |
| - | - |
| `openai/gpt-4o` | `gpt-4o` |
| `google/gemini-2.5-flash` | `gemini-2.5-flash` |
| `anthropic/claude-haiku-4-5` | `aws/claude-haiku-4-5`, if the AWS-backed option meets your requirements |
| Any other model or version | Look up the exact available ID; do not invent a mapping. |

<Warning>
  Do not apply a universal “remove the provider prefix” rule.

  NexLLM documents both unprefixed and prefixed IDs. A mapping can also change the hosting provider, so matching the model family alone is insufficient.
</Warning>

Keep model-version changes separate from the gateway migration where practical. If the original model is unavailable, evaluate the substitute explicitly.

The Models API establishes availability to your key. Check model details separately for endpoint compatibility and required capabilities.

See [Model Details](/channel-groups/pricing-overview).

## Step 6: Reconnect Observability

NexLLM Usage Logs include request time, key name, model, timing, token consumption, and cost or quota deducted.

See [Usage & Logs](/account/usage-logs-and-statistics).

| Existing requirement | Migration approach |
| - | - |
| Request-level consumption and timing | Review NexLLM Usage Logs. |
| Application or environment attribution | Use descriptive key names and retain application metadata in your own logs. |
| Deployment-level tracing | Keep your existing tracing system connected to the migrated client. |
| Routing decisions and retry history | Record application-managed choices and attempts yourself. |
| Spend and access controls | Review NexLLM wallet usage and API key quota settings. |
| Gateway-specific provider metadata | Update dashboards and parsers to the fields actually available after migration. |

See [API Keys](/get-started/getting-your-api-keys) and [Wallet](/account/wallet-and-top-up).

### Keep Application Correlation IDs

For each inference operation, consider recording:

* Your application request ID.
* Environment and application version.
* Requested model.
* Returned completion ID, where applicable.
* Duration and outcome.
* Retry or fallback attempt.
* Token usage when returned.

Do not log credentials. Apply your existing controls to prompt and response content.

### Preserve Your AI Gateway History

Before reducing access to the previous gateway:

1. Identify historical records required for operations or audits.
2. Check the export or retention mechanisms available to your account.
3. Preserve available logs, billing records, and routing configuration.
4. Verify that archived records remain readable.
5. Document the cutover time.

Do not assume historical Vercel records will automatically appear in NexLLM.

## Step 7 (Optional): Evaluate the Responses API

NexLLM lists an OpenAI Responses-compatible endpoint:

```text theme={null}
POST https://www.nexllm.ai/v1/responses
```

See [API Reference](/api-reference/overview).

If your application already uses Responses, evaluate that endpoint before converting the workflow to Chat Completions.

Select a model whose details show Responses compatibility. The model browser supports filtering by endpoint type.

See [Model Details](/channel-groups/pricing-overview).

### Minimal Compatibility Test

The following is a minimal Responses-format request pattern. Replace the placeholder with a compatible model available to your key:

```bash theme={null}
curl https://www.nexllm.ai/v1/responses \
  -H "Authorization: Bearer $NEXLLM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "REPLACE_WITH_RESPONSES_COMPATIBLE_MODEL_ID",
    "input": "Write a short greeting."
  }'
```

<Warning>
  The documented endpoint does not, by itself, establish feature parity with every gateway or provider.

  Verify response chaining, storage, reasoning, tools, structured output, multimodal inputs, and streaming for your selected model. Do not assume `previous_response_id` or provider-specific tools work identically.
</Warning>

For the AI SDK, select `.responses(modelId)` only as a deliberate endpoint choice. Retest response parsing and streaming behavior.

## Why Migrate to NexLLM

### Keep an OpenAI-Compatible Integration

Use the documented Chat Completions interface while accessing GPT, Claude, and Gemini models.

See [Quickstart](/get-started/quickstart).

### Choose Model Access and Pricing Through Channel Groups

Select a group appropriate for your workload rather than assuming the previous gateway's routing policy transfers unchanged.

See [Channel Groups](/channel-groups/overview).

### Configure Purpose-Specific Credentials

Separate development, production, or workload credentials using NexLLM's key controls.

See [API Keys](/get-started/getting-your-api-keys).

### Review Usage in One Dashboard

Use request logs and consumption statistics to evaluate the migration.

See [Usage & Logs](/account/usage-logs-and-statistics).

<Note>
  Validate the benefits against your own acceptance criteria. This guide does not promise identical routing, automatic fallback, BYOK terms, retention policies, service tiers, or latency.
</Note>

## Troubleshooting

<AccordionGroup>
  <Accordion title="The model is not found">
    Call `GET /v1/models` using the application's actual key.

    Check the exact identifier, the assigned channel group, and any model restrictions. Do not assume the previous gateway's prefix is accepted.

    See [Models API](/api-reference/models).
  </Accordion>

  <Accordion title="Authentication fails">
    Confirm the application sends a NexLLM key rather than an AI Gateway key, OIDC token, or upstream provider credential.

    Check secret availability in the running process, configured expiration, IP restrictions, and accidental whitespace.

    Use bearer authentication for the OpenAI-compatible examples and native headers for the Claude Messages example.

    See [Authentication](/api-reference/authentication).
  </Accordion>

  <Accordion title="AI SDK requests still go through Vercel AI Gateway">
    Inspect every model construction site.

    Replace implicit gateway strings and `gateway(...)` instances with the configured NexLLM provider where migration is intended.

    Check shared registries, background jobs, streaming routes, and default provider configuration. Preserve intentional gateway usage elsewhere.
  </Accordion>

  <Accordion title="The AI SDK calls /responses unexpectedly">
    For Chat Completions, use:

    ```javascript theme={null}
    model: nexllm.chat(modelId)
    ```

    Do not rely on the default OpenAI provider factory to select your intended endpoint.
  </Accordion>

  <Accordion title="Claude-native requests return 404">
    Inspect the final URL.

    The complete Messages endpoint is:

    ```text theme={null}
    https://www.nexllm.ai/v1/messages
    ```

    For the Anthropic SDK example in this guide, use the host-only base URL:

    ```text theme={null}
    https://www.nexllm.ai
    ```

    Check for duplicated `/v1` segments, missing path segments, or a client still pointing to the previous gateway.
  </Accordion>

  <Accordion title="Requests succeed but do not appear in NexLLM logs">
    Verify the actual destination, credential, account, and log time range.

    Check independently initialized clients and background workers. Avoid printing authorization headers while debugging.

    See [Usage & Logs](/account/usage-logs-and-statistics).
  </Accordion>

  <Accordion title="Provider routing or fallback no longer applies">
    Review the removed gateway options and the requirements behind them.

    A channel-group selection is not proof that a per-request provider allowlist, ordering rule, or fallback chain has been reproduced.

    Restore affected traffic to the previous route until required constraints are verified.
  </Accordion>

  <Accordion title="Cache behavior or cost changed">
    Compare model IDs, request formats, prompt structure, cache behavior, token accounting, and the applicable group ratio.

    Do not assume the original gateway's automatic cache configuration transfers to NexLLM.

    See [Pricing](/channel-groups/pricing-overview).
  </Accordion>

  <Accordion title="Connection checks fail">
    Test the documented Models endpoint first:

    ```bash theme={null}
    curl -i https://www.nexllm.ai/v1/models \
      -H "Authorization: Bearer $NEXLLM_API_KEY"
    ```

    Then run a small inference request.

    A successful model-list request does not validate every inference feature. Do not invent a `/health` endpoint based on another gateway's documentation.
  </Accordion>
</AccordionGroup>

## Verification Checklist

Before completing the cutover:

* [ ] Production clients use the intended NexLLM endpoint.
* [ ] Credentials remain server-side.
* [ ] Exact model IDs are verified using the production key.
* [ ] Channel-group and key restrictions are reviewed.
* [ ] Plain-text requests pass.
* [ ] Streaming passes, including cancellation and partial failures.
* [ ] Tool calls pass without duplicate execution.
* [ ] Structured outputs meet the original validation requirements.
* [ ] Required multimodal inputs work.
* [ ] Routing, retries, timeouts, and fallbacks are explicitly tested.
* [ ] Privacy and provider restrictions are preserved.
* [ ] Logging and consumption monitoring work.
* [ ] Representative quality, latency, and cost checks pass.
* [ ] Historical records remain accessible.
* [ ] A rollback procedure is tested.
* [ ] Old credentials are removed only after remaining dependencies are checked.

## Next Steps

<CardGroup cols={2}>
  <Card title="API Reference" href="/api-reference/overview">
    Review supported endpoint formats.
  </Card>

  <Card title="Available Models" href="/api-reference/models">
    Discover model IDs available to your key.
  </Card>

  <Card title="Channel Groups" href="/channel-groups/overview">
    Review access and pricing configuration.
  </Card>

  <Card title="Usage & Logs" href="/account/usage-logs-and-statistics">
    Inspect requests after migration.
  </Card>
</CardGroup>

## Feedback

When reporting migration issues, include:

* The client package and version.
* The endpoint and model ID.
* The behavior expected from the previous integration.
* A sanitized request example.
* The HTTP status and error body.
* The approximate request time.
* A completion or request identifier, if available.

Remove credentials, private prompts, and personal data before sharing diagnostics.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.