---
title: "Migrate from OpenAI to an EU-hosted API · step-by-step guide"
description: "Move an application from OpenAI to open models processed in the EU. Change the base URL, key and model, then check tools, JSON output and embeddings."
canonical: "https://inference.eu/api/migrate-from-openai/"
language: "en"
---

Guides · Migrate from OpenAI

# Migrating from OpenAI to the inference.eu API: a practical guide

If your application already uses the OpenAI API, moving to open-weight models processed in European data centres is mostly a configuration change. This guide covers the three lines you change, how to pick replacement models, which features to test before you switch production traffic, and how to roll the change out without surprises.

[Contact sales](https://inference.eu/contact/)[Example request](#example)

1.  01API format: OpenAI
2.  02EU data centres
3.  03Covered by one DPA

app.py

```
import os
from openai import OpenAI

# Before: client = OpenAI()  # api.openai.com, OPENAI_API_KEY
client = OpenAI(
    base_url="https://api.inference.eu/v1",
    api_key=os.environ["INFERENCE_EU_API_KEY"],
)

reply = client.chat.completions.create(
    model="gpt-oss-120b",  # was "gpt-4o"
    messages=[{"role": "user", "content": "Draft a polite reminder for an unpaid invoice."}],
)
print(reply.choices[0].message.content)
```

## The three changes

Point the client at the inference.eu base URL, use your inference.eu key, and change the model name. In the OpenAI Python and JavaScript SDKs that means passing `base_url` (or `baseURL`) and `api_key` when you create the client, or setting the `OPENAI_BASE_URL` and `OPENAI_API_KEY` environment variables, which the SDKs read automatically.

Everything else stays: the same SDK version, the same `client.chat.completions.create` and `client.responses.create` calls, the same streaming loop and the same error classes. Frameworks such as LangChain, LlamaIndex, the Vercel AI SDK and the OpenAI Agents SDK take the same two settings. Keep the model id in configuration, so the migration is a deployment setting you can roll back.

## Choosing replacement models

Map each use to a model rather than looking for one model that replaces everything. For general chat and agent work, a large open model such as `gpt-oss-120b` is a common starting point. For high-volume classification or extraction, a smaller and faster model often does the job. For embeddings, `qwen3-embedding-8b` covers multilingual text, and `whisper-large-v3-turbo` replaces OpenAI's transcription models.

Embeddings are the one place where you cannot mix: vectors from OpenAI models are not comparable with vectors from open models, so re-embed your collection with the new model before you switch search over. Run the batch API for that, then swap the index in one step.

## What to test before switching

Build a small evaluation set from real traffic: 50 to 200 prompts with the answers you consider good. Run it against the old and the new setup and compare quality, length and format, not just whether the request succeeds.

Check the features you rely on. Tool calling should produce the same function names and valid arguments. Structured outputs should pass your JSON schema. Streaming should end with a final chunk and usage. Vision prompts need a vision-capable model. Prompts tuned heavily for one model sometimes need small edits, such as a clearer instruction about output format or language, to get the best from another.

## Rolling out and edge cases

Move traffic gradually. Send a small share of requests to inference.eu, compare error rates and user feedback, then increase. Because the request format is the same, a feature flag that chooses the base URL and model is usually enough.

Some OpenAI-only features have no direct equivalent: OpenAI's own model names, its hosted assistants and vector stores, and settings tied to specific OpenAI models. Fields a model does not support are ignored or rejected with a clear 400 error, so watch your logs during the first days. Check rate limits for your plan before moving peak traffic, and ask us to raise them in good time.

## Migrate from OpenAI

Category

Guides

API format

OpenAI

Base URL

api.inference.eu/v1

Processing

EU data centres

Training on your data

Never

## Migrate from OpenAI: common questions

The questions buyers, developers and legal teams ask us most. Something missing? Ask us directly.

Change three things: the base URL to the inference.eu API, the API key to your inference.eu key, and the model name to an open model id such as \`gpt-oss-120b\`. The OpenAI SDKs and most frameworks accept the first two as constructor arguments or the \`OPENAI\_BASE\_URL\` and \`OPENAI\_API\_KEY\` environment variables.

Usually not. Requests, responses, streaming and errors use the same OpenAI format, so the rest of your code keeps working. You may need to adjust prompts that depend on one model's habits, and remove calls to OpenAI-only services such as hosted vector stores.

There is no single answer, because it depends on the task. Large open models such as \`gpt-oss-120b\` handle general chat, reasoning and tool use well. Test two or three candidates on your own evaluation set and choose per feature. The model pages describe each model's strengths and context length.

No. Vectors from OpenAI embedding models cannot be compared with vectors from open embedding models. Re-embed your documents with the new model, ideally with the batch API, build a new index, and switch search over once it is complete. Keep the old index until the new one is verified.

OpenAI's hosted Assistants and its vector stores are not part of the inference.eu API. Most teams replace them with the Responses API or chat completions plus their own retrieval: embeddings, a vector database and a reranker. That also keeps your documents in infrastructure you control.

Yes. Because the request format is the same, switching back means changing the base URL, key and model again. Keep these in configuration or behind a feature flag so you can move traffic in either direction while you evaluate.

Rate limits on inference.eu depend on your plan and the models you use, and we agree them with you rather than using fixed public tiers. Tell us your expected peak traffic before migrating so we can set limits that fit, and keep retry logic for HTTP 429 in place.

Requests are processed in European data centres instead of by a US provider, and they are never used to train models. Update your records of processing and your list of subprocessors to reflect the change, and ask us for the contract documents your legal team needs.

[Ask a question](https://inference.eu/contact/)

## Related

[API overview](https://inference.eu/api/)

-   [Chat completionsSend chat messages to open-weight models with the OpenAI chat completions format. Requests are processed in EU data centres and never used for training.Endpoints](https://inference.eu/api/chat-completions/)
-   [List modelsList the open-weight models your inference.eu key can use with GET /v1/models, in the OpenAI format. Pick model ids for chat, embeddings, speech and more.Endpoints](https://inference.eu/api/models/)
-   [Rate limits and errorsHow rate limits and errors work on the inference.eu API. HTTP status codes, the error object, rate-limit headers and a retry pattern that holds up.Guides](https://inference.eu/api/rate-limits-and-errors/)
-   [Structured outputsGet valid JSON that matches your schema from open models with OpenAI-compatible structured outputs. JSON mode, json\_schema, strict mode and pitfalls.Guides](https://inference.eu/api/structured-outputs/)

## Move your AI workloads to EU infrastructure

Tell us which models you use and roughly how much traffic you have. We reply within one working day with pricing and next steps.

-   Reply within one working day
-   Pricing for your volume
-   DPA ready to sign