How to migrate from the official APIs or another OpenAI-compatible service

Moving to Tutujin API usually changes three things in your code: base_url becomes https://www.tutujin.com/v1, api_key becomes a key you create in the console, and model becomes a name from this site's model hub. The real work is the checking before launch and the switch after it: confirm the models with the models endpoint, check the differences in streaming, error codes and rate limits, then move traffic over in stages — a small share, half, then all of it. Keep the old service until the full rollout is stable, and keep the share in configuration so a rollback is just setting it back to 0.

Check before you migrate

Supported endpoints:

Step 1: create a key and change the base URL

Create a key just for the migration on the API keys page of the console, with a spending cap and a group. Then change your configuration for the way you call the API today:

Replace api_key with your key from this site in every case. Projects that read environment variables can switch without touching code:

export OPENAI_BASE_URL="https://www.tutujin.com/v1"
export OPENAI_API_KEY="sk-your-key"

The three header styles and full SDK setups are in Authentication and base URL.

Step 2: check the model names

Call the models endpoint with the new key; it returns exactly the models that key can use:

curl https://www.tutujin.com/v1/models \
  -H "Authorization: Bearer $TUTUJIN_API_KEY"

Match every model name your code uses against the response. The same model may be named differently on different platforms; this site's name is the one that works here, so map any mismatches in code. If a model is missing, the key's group most likely does not offer it — check the model's page for its groups, and see Models endpoint.

Step 3: check the behavior differences

The API format is compatible, but a few behaviors need handling the way this site works:

The full status code table is in Errors and retries, and the billing fields are explained in Billing and usage.

Step 4: roll out in stages

Do not switch everything at once. Route by percentage and look at the data before each next stage:

Pin each user or session to one side, so comparisons and debugging stay clear. Keep the share in an environment variable or a config service, so changing it or rolling back needs no code change:

import os
import zlib

from openai import OpenAI

tutujin = OpenAI(base_url="https://www.tutujin.com/v1", api_key=os.environ["TUTUJIN_API_KEY"])
legacy = OpenAI(base_url=os.environ["OLD_BASE_URL"], api_key=os.environ["OLD_API_KEY"])

# old service's model name -> this site's model name, e.g. names with a vendor prefix
MODEL_MAP = {"openai/gpt-4.1-mini": "gpt-5.4-mini"}


def rollout() -> float:
    # 0 = everything to the old service, 1 = everything here; read on every call so changes apply at once
    return float(os.environ.get("TUTUJIN_ROLLOUT", "0"))


def chat(user_id: str, model: str, messages: list):
    bucket = zlib.crc32(user_id.encode()) % 100  # the same user always lands in the same bucket
    if bucket < rollout() * 100:
        return tutujin.chat.completions.create(model=MODEL_MAP.get(model, model), messages=messages)
    return legacy.chat.completions.create(model=model, messages=messages)

import OpenAI from 'openai'
import { crc32 } from 'node:zlib'

const tutujin = new OpenAI({ baseURL: 'https://www.tutujin.com/v1', apiKey: process.env.TUTUJIN_API_KEY })
const legacy = new OpenAI({ baseURL: process.env.OLD_BASE_URL, apiKey: process.env.OLD_API_KEY })

// old service's model name -> this site's model name, e.g. names with a vendor prefix
const MODEL_MAP = { 'openai/gpt-4.1-mini': 'gpt-5.4-mini' }

// 0 = everything to the old service, 1 = everything here; read on every call so changes apply at once
const rollout = () => Number(process.env.TUTUJIN_ROLLOUT ?? '0')

export function chat(userId, model, messages) {
  const bucket = crc32(userId) % 100 // the same user always lands in the same bucket
  if (bucket < rollout() * 100) {
    return tutujin.chat.completions.create({ model: MODEL_MAP[model] ?? model, messages })
  }
  return legacy.chat.completions.create({ model, messages })
}

The Python and Node.js versions put the same user in the same bucket, so mixed services stay consistent. At every stage, filter Logs in the console by the migration key's name to check request counts, errors and spend, and compare them with what you recorded from usage in your own system.

Rolling back

• If something goes wrong, set the share back to 0 first. All requests return to the old service at once, with no code change and no redeploy.
• After the full rollout, keep the old service's account and keys for a while until the new setup has proven stable.
• After a rollback, use the time, model and error details in Logs to find the cause; if you need our help, send the request id from the error to WeChat support at JsnonoChat.

After the switch

• Give production keys a spending cap and an IP allowlist; see API key security best practices.
• For critical workloads, give the key several groups and turn on cross-group retry; see LLM API high availability.
• Export usage by key every month for reconciliation; see Cost allocation and reconciliation.