Bottom line: Projects that already use the OpenAI SDK can usually migrate to AIFast by replacing the Base URL, API Key, and Model ID. Before migrating, confirm whether the project uses Chat Completions or Responses API; "Compatible with OpenAI" does not mean that all endpoints and advanced parameters are exactly the same.
If you are searching for how to use OpenAI API from China, the shortest path is to create a separate key on the target platform and request /models the real model ID visible to the current account, then send a short non-streaming request with the same key and model. After the basic request succeeds, verify SSE, tool calls, error codes, and usage fields separately; do not treat a successful third-party gateway response as proof that every OpenAI endpoint is compatible.
Find three configurations before migrating
| Project configuration | AIFast recommended value |
|---|---|
| Base URL | https://www.aifast.link/v1 |
| API Key | Independent Key for projects created by the console |
| Model | /v1/models The real ID returned |
It is recommended to migrate in the test environment first instead of directly replacing the production configuration. Create independent keys for different projects and set controllable limits, which can be revoked individually when leaks occur or use is stopped.
Step 1: Confirm the model and basic links
export AIFAST_API_KEY="your_API_Key"
curl --fail-with-body --silent --show-error \
https://www.aifast.link/v1/models \
-H "Authorization: Bearer $AIFAST_API_KEY"
Successful return contains data The model list response of the array indicates that the domain name, HTTPS, and Bearer authentication links are basically normal. Then copy the real model ID from the response:
export MODEL_ID="real copied from model list_ID"
Step 2: Migrate the Python project
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["AIFAST_API_KEY"],
base_url="https://www.aifast.link/v1",
)
response = client.chat.completions.create(
model=os.environ["MODEL_ID"],
messages=[
{"role": "system", "content": "Answers must be concise。"},
{"role": "user", "content": "list API Three checks before migrating。"},
],
)
print(response.choices[0].message.content)
If the original project uses OPENAI_API_KEY, do not keep multiple Keys from unknown sources at the same time. Clarify the priority of environment variables to prevent the program from reading the official OpenAI Key while the request is sent to the third-party Base URL, or vice versa.
Step Three: Migrate Node.js Project
import OpenAI from "openai";
const client = new OpenAI({
apiKey: process.env.AIFAST_API_KEY,
baseURL: "https://www.aifast.link/v1",
});
const response = await client.chat.completions.create({
model: process.env.MODEL_ID,
messages: [
{ role: "user", content: "Reply with only OPENAI_COMPATIBLE_READY" },
],
temperature: 0,
});
console.log(response.choices[0].message.content);
Complete non-streaming short requests first, then add streaming, tool calls, image input, or structured output. Adding too many parameters at once will make it difficult to locate the source of the error.
How to choose between Chat Completions and Responses
| Project status | Recommended verification path |
|---|---|
Already used chat.completions.create |
Verify first /v1/chat/completions, the lowest migration cost |
| Used Responses API | First check whether the target model and entrance are supported /v1/responses |
| Use tool call | Separately verify tool name, parameter JSON and multiple rounds of postback |
| Use images, audio or files | Acceptance is based on specific endpoints one by one, and is not inferred based on the success of the text API. |
ViewLLM API Compatibility MatrixEndpoint boundaries that require verification can be quickly confirmed.
How do you confirm compatibility after migration?
Split acceptance testing into four layers to avoid production failures behind an HTTP 200 response:
| Acceptance layer | Minimum evidence | Conclusion that cannot be inferred directly |
|---|---|---|
| Authentication and catalog | /v1/models Status code, real model ID, and request ID |
Does not prove chat, streaming, or tool calls work |
| Basic request | Parseable response,model、usage and error structure |
Does not prove long-context stability |
| Streaming and tools | Complete SSE termination marker, tool name, and JSON arguments | Does not prove compatibility with every client adapter |
| Business task | Fixed test set, results across multiple time windows, and billing records | A single success cannot prove a long-term SLA |
When comparing multiple endpoints, keep the model ID, prompts, parameters, and time window fixed. Change only the Base URL so the results remain comparable.
Five Minute Acceptance Checklist
/v1/modelsReturns parsable JSON instead of HTML.- Minimal request returns expected structure and saves
model、usageand request ID. - Error Key returns clear 401/403 without revealing sensitive information.
- Streaming requests can continuously read SSE instead of waiting for a complete response and outputting it all at once.
- Billing changes can correspond to model, token, key and request time.
To compare existing APIs, useFree model checkingCheck protocols, model declarations, tokens, SSE and tool calls. The test results are not certified by the underlying manufacturer and should be judged based on multi-period samples and real business question sets.
Next step
Continue readingOpenAI Compatible quick access、401, 429, 502 error troubleshootingandProduction on-line checklist, then run a staged migration and rollback drill.