OpenAI compatibility

Use the OpenAI SDK with Inworld Inference for chat completions, responses, and moderations. Set the base URL and authentication as shown below to use Inworld Inference in your existing apps.

Credential handling

Run these examples on your server. Set INWORLD_API_KEY to the complete Base64 credentials copied from Portal or the CLI, without encoding them again. The router accepts the credential as Authorization: Bearer ..., which is what the OpenAI SDK sends from api_key, and as Authorization: Basic .... The default_headers / defaultHeaders line in the examples switches the SDK to Basic, to match direct HTTP requests. It is optional: without it, the SDK's Bearer header works. Browser/mobile clients need a backend-minted token, never the server API key.

Endpoint

The OpenAI-compatible API endpoint is available at:

https://api.inworld.ai/v1

To use Inworld Inference, change your API call URL or SDK base URL from https://api.openai.com/v1 to https://api.inworld.ai/v1.

Supported endpoints

For tasks that OpenAI serves on other endpoints:

• Generate images: call client.chat.completions.create with modalities: ["text", "image"]. See Image generation.
• List models: use the List Models API. /v1/models is not served, so client.models.list() returns 404.
• Text-to-speech in OpenAI's /v1/audio/speech format: see TTS OpenAI compatibility.

Other OpenAI endpoints, including /v1/images/generations, /v1/embeddings, /v1/batches, and the file endpoints, are not served.

OpenAI SDK

Send a request with OpenAI's SDK:

import os
from openai import OpenAI

api_key = os.environ["INWORLD_API_KEY"]

# Initialize the client with Inworld Inference credentials
client = OpenAI(
    base_url="https://api.inworld.ai/v1",
    api_key=api_key,
    default_headers={"Authorization": f"Basic {api_key}"},
)

# Call your router
response = client.chat.completions.create(
    model="inworld/<router-id>",
    messages=[
        {"role": "user", "content": "Who created you?"}
    ]
)

print(response.choices[0].message.content)

import OpenAI from 'openai';

const apiKey = process.env.INWORLD_API_KEY;
if (!apiKey) throw new Error('Set INWORLD_API_KEY to your copied Base64 credential');

const openai = new OpenAI({
  baseURL: 'https://api.inworld.ai/v1',
  apiKey,
  defaultHeaders: { Authorization: `Basic ${apiKey}` },
});

async function main() {
  const completion = await openai.chat.completions.create({
    messages: [{ role: 'user', content: 'Who created you?' }],
    model: 'inworld/demo-router'
  });

  console.log(completion.choices[0].message.content);
}

main();

Responses API

The same client works with the Responses API:

response = client.responses.create(
    model="inworld/<router-id>",
    input="Who created you?",
)

print(response.output_text)

See the Responses API guide for streaming, tools, and stored responses.

Inworld request fields

Inworld adds request fields that OpenAI's API does not have, such as fallback models, sort, ignore, provider, fallback, session, web_search, and compression. The OpenAI SDKs don't define these fields, so pass them as extra parameters:

• Python: put them in extra_body. The SDK adds its keys to the top level of the JSON body.
• Node: add them to the request object. The SDK sends them as-is. In TypeScript, keep them in a separate object and spread it into the request, as in the example below, so the request still type-checks.
• Direct HTTP: put them at the top level of the body, or inside an extra_body object. If both set the same field on chat completions, the top-level value is used.

response = client.chat.completions.create(
    model="auto",
    messages=[{"role": "user", "content": "Who created you?"}],
    extra_body={"sort": ["price"]},
)

// Inworld request fields that the SDK's types don't define.
const inworld = { sort: ["price"] };

const completion = await openai.chat.completions.create({
  model: "auto",
  messages: [{ role: "user", content: "Who created you?" }],
  ...inworld,
});

Fields that belong inside a message, such as cache_control on a content part, go in messages as usual. See request-level routing for the routing fields. The Responses API accepts only some of these fields; see its routing options.