Cấu hình API bên thứ ba cho Codex cần `base_url` có `/v1`, `env_key` là tên biến môi trường và `wire_api = “responses”` để gọi trực tiếp `/v1/responses`. Bài này giúp bạn đọc đúng file cấu hình, thêm một provider mới và kiểm tra request mà không nhầm API key với tên biến. Bạn sẽ biết vì sao `base_url` thiếu `/v1` có thể khiến đường dẫn thành `/responses` sai, còn `env_key` phải trỏ tới tên như `THIRD_PARTY_API_KEY`, không phải chuỗi khóa thật. Các thông số như `model_provider`, `model`, `base_url` và `wire_api` được đặt cạnh nhau để bạn đối chiếu trước khi chạy Codex.

Tóm tắt nhanh

• `base_url` nên kết thúc ở `/v1` để Codex ghép thành endpoint `/v1/responses`.
• `env_key = “THIRD_PARTY_API_KEY”` là tên biến; giá trị khóa được nạp bằng biến môi trường.
• `wire_api = “responses”` yêu cầu gọi giao thức Responses, không tự chuyển sang Chat Completions. Nguồn SERP mô tả ba nhóm thông tin thường gặp là API key, base URL và model ID; tài liệu cấu hình cũng dùng các trường `model_provider`, `base_url` và `OPENAI_API_KEY`. Vì vậy, trước khi sửa file, bạn cần xác nhận provider có endpoint và model ID tương ứng; tên trường đúng chưa đảm bảo mọi provider hỗ trợ đầy đủ Responses API.

Điểm dễ nhầm nằm ở chỗ Codex không tự biến mọi API thành API OpenAI. Codex là client đọc file cấu hình, chọn provider rồi gửi request theo giao thức đã khai báo. Vì vậy, thêm một provider mới không chỉ là dán API key và đổi `model`; máy chủ phía sau cũng phải nhận được kiểu request và trả về định dạng response mà Codex hiểu. `base_url` là địa chỉ thư mục API, không phải endpoint hoàn chỉnh của một lần tạo nội dung. Chẳng hạn, giá trị minh họa phải có dạng ` trong đó `/v1` là phần đường dẫn cần giữ lại nếu nhà cung cấp đặt API dưới thư mục này. Codex sau đó ghép thêm `/responses`, tạo thành request đi tới ` Nếu chỉ nhập ` request có thể rơi vào `404` dù API key vẫn đúng. Một khác biệt dễ gây lỗi khác nằm ở `env_key`. Trường này là tên biến môi trường, chẳng hạn `THIRD_PARTY_API_KEY`, chứ không phải chuỗi khóa thật như `sk-example-123`. Giá trị khóa được đặt trong môi trường chạy Codex; file cấu hình chỉ tham chiếu tên biến. Nhầm hai loại giá trị này khiến Codex không đọc được thông tin xác thực hoặc khiến khóa bị ghi thẳng vào file. Với cấu hình dùng Responses API, `wire_api` phải là `”responses”`. Thiết lập này nói cho Codex gửi trực tiếp tới `/v1/responses`, thay vì chuyển request sang Chat Completions. Một số tài liệu cấu hình còn dùng các trường như `model_provider`, `base_url` và `OPENAI_API_KEY`; khi áp dụng, bạn cần giữ đúng cấu trúc mà phiên bản Codex đang đọc. Việc trộn đồng thời `model_provider` và `model_providers` có thể dẫn tới `401`, `404` hoặc request đi sai endpoint, theo cảnh báo trong tài liệu được khảo sát.

Một file cấu hình Codex có thể nhìn đúng cú pháp nhưng vẫn gọi sai dịch vụ nếu lệch một trong bốn điểm: đường dẫn `base_url`, tên model, biến chứa khóa và giao thức request. Với API bên thứ ba, hãy kiểm tra chuỗi endpoint hoàn chỉnh mà Codex sẽ tạo ra, thay vì chỉ nhìn từng giá trị riêng lẻ. `base_url` cần trỏ đến phần gốc có `/v1`; khi `wire_api = “responses”`, request đích phải là `base_url + /responses`, tức dạng `/v1/responses`. Codex đi thẳng qua Responses API, không tự dịch request sang Chat Completions. Vì vậy, một provider chỉ có `/v1/chat/completions` chưa đủ để kết luận là dùng được.

Các trường cần đối chiếu

Lỗi dễ gặp nhất nằm ở đường dẫn ghép sai: nếu `base_url` đã là ` Codex phải gửi request đến ` Bạn cần xác nhận provider nhận được giao thức Responses API hoặc giao thức tương thích mà Codex yêu cầu, thay vì chỉ thấy quảng cáo “tương thích OpenAI”. Mở tài liệu provider và kiểm tra ba điểm: endpoint Responses có tồn tại, header xác thực dùng `Authorization: Bearer` hay cơ chế khác, và model ID nào được chấp nhận. Một provider chỉ công bố `/v1/chat/completions` chưa đủ để kết luận có thể dùng với cấu hình `wire_api = “responses”`; hãy hỏi tài liệu hoặc log request trước khi thêm vào Codex.

2. Chuẩn bị thông tin trước khi sửa file Ghi riêng API key, tên biến môi trường và model ID. Ví dụ, giá trị bí mật nằm trong `THIRD_PARTY_API_KEY`, còn `env_key` chỉ ghi đúng chuỗi `THIRD_PARTY_API_KEY`, không ghi `sk-…` vào file cấu hình. Model ID như `provider-coder-1` cũng phải khớp chính tả với danh sách model

của provider. Mở file cấu hình Codex hiện có hoặc tạo file theo cấu trúc mà phiên bản Codex của bạn sử dụng. Một khung TOML có thể trông như sau:

[model_providers.third_party]
base_url = ""
env_key = "THIRD_PARTY_API_KEY"
wire_api = "responses" [profiles.third_party]
model_provider = "third_party"
model = "provider-coder-1"

Tên section `model_providers.third_party` và `profiles.third_party` cần đối chiếu với tài liệu phiên bản Codex đang chạy. Điểm không được đổi trong workflow này là `base_url` có `/v1`, `env_key` là tên biến, và `wire_api` là `responses`.

3. Kiểm tra biến môi trường và cấu hình Đặt key trong phiên shell trước khi chạy Codex, chẳng hạn `export THIRD_PARTY_API_KEY=”your-key”`, rồi kiểm tra biến đã tồn tại mà không in giá trị ra log. Nếu file còn đồng thời `model_provider` cũ và `model_providers` cũ ở các section cạnh tranh, hãy rà lại tên tham chiếu; tài liệu SERP cảnh báo việc trộn các mục này có thể làm request đi sai provider hoặc gây `401` và `404`.

4. Gửi request và đọc lỗi theo thứ tự Cho Codex gửi thử một request tối giản tới `/v1/responses` với model ID đã xác nhận và một input ngắn như `Xin chào`. Nếu nhận `401`, kiểm tra tên biến, giá trị key và header xác thực; nếu nhận `404`, kiểm tra lại `/v1`, đường dẫn `/responses` và provider

được chọn. Khi HTTP đã thành công, đọc response schema: xác nhận có trường văn bản mà Codex hiểu, thay vì chỉ thấy mã `200` rồi xem là xong.

Nhãn “tương thích OpenAI” chưa đủ để kết luận provider dùng được với Codex. Một provider có thể nhận request kiểu OpenAI nhưng không hỗ trợ đầy đủ `POST /v1/responses`; khi đó cấu hình `wire_api = “responses”` vẫn có thể trả `404`, `400` hoặc response không đúng schema. Bạn cần xác nhận endpoint này trong tài liệu provider, thay vì suy ra từ việc provider có Chat Completions. Model ID cũng không mặc nhiên trùng với tài liệu Codex. Provider có thể yêu cầu tên như `vendor/model-name`, dùng tham số đầu vào khác, hoặc giới hạn context thấp hơn model bạn đang quen dùng. Một prompt dài kèm lịch sử phiên có thể vượt giới hạn dù file cấu hình vẫn hợp lệ. Hãy kiểm tra riêng model ID, tên trường request và giới hạn token trước khi kết luận lỗi nằm ở Codex. Proxy là thêm một lớp có thể làm thay đổi hành vi request. Nó có thể yêu cầu `Authorization: Bearer`, một header khác, hoặc dùng biến môi trường riêng; cũng có proxy không chuyển tiếp streaming hay đổi cấu trúc trường trong response. Vì vậy lỗi `401` có thể đến từ authentication, còn `404` có thể do proxy ghép sai đường dẫn khi `base_url` đã chứa `/v1`. Giữ lại đồng thời các mục `model_provider` và `model_providers` cũng có thể khiến request đi sai cấu hình. Đừng tự điền giá, quota hay độ ổn định vào tài liệu nếu chưa kiểm thử. Hãy ghi rõ provider, model ID và thời điểm kiểm tra, rồi chạy các ca tối thiểu: prompt ngắn, prompt vượt context dự kiến, response streaming và lỗi authentication. Chúng tôi chưa có số đo chung để khẳng định provider nào rẻ hơn, nhanh hơn hoặc ổn định hơn khi chạy qua Codex.

Một developer Việt Nam có thể dùng Codex như lớp kiểm tra provider trước khi đưa API mới vào sản phẩm: xác nhận model ID, kiểm tra `base_url` có `/v1`, rồi gửi request đến `/v1/responses`. Cách này phù hợp khi team đang cân nhắc nhiều nhà cung cấp nhưng chưa muốn đổi toàn bộ code gọi model.

Tình huống 1: developer kiểm tra provider mới Giả sử một freelancer nhận dự án chatbot chăm sóc khách hàng và muốn thử provider khác OpenAI. Anh ta tạo một profile riêng trong file cấu hình Codex, đặt `model_provider`, `base_url` và `model`, sau đó dùng `wire_api = “responses”`. Biến `env_key`

được trỏ tới tên biến môi trường như `THIRD_PARTY_API_KEY`, còn giá trị khóa nằm ngoài file cấu hình. Bài kiểm tra đầu tiên chỉ cần xác nhận request đi đúng `POST /v1/responses` và trả về schema mà Codex đọc được. Nếu nhận `401`, kiểm tra biến môi trường và header xác thực; nếu nhận `404`, kiểm tra lại phần `/v1` và đường dẫn `/responses`. Khi có nhiều profile, team nên giữ một tên duy nhất cho mục provider, tránh trộn `model_provider` với `model_providers`, vì tài liệu SERP cảnh báo cấu hình lẫn hai mục này có thể dẫn tới request sai endpoint.

Tình huống 2: marketer chuyển sang workflow Một marketer bán hàng online có thể nhờ developer xác nhận provider bằng một prompt cố định, chẳng hạn tạo 3 biến thể mô tả cho cùng một sản phẩm. Sau khi request `/v1/responses` trả về đúng nội dung và định dạng cần dùng, marketer đưa prompt, model ID và bước kiểm duyệt vào AI Studio Workflow để chạy thử các khâu tiếp theo. Workflow nên giữ rõ đầu vào và đầu ra: `input` là thông tin sản phẩm, đầu ra là trường văn bản

được gắn vào bước duyệt nội dung. Không nên xem lần chạy thử là bằng chứng về chi phí, quota hay tốc độ; các thông số đó phải được kiểm tra riêng theo tài liệu provider.

Mini case study: kiểm tra trước khi nối automation Một nhóm nhỏ bắt đầu bằng việc tạo profile provider mới, xác nhận `/v1/responses` hoạt động với một model ID cụ thể, rồi chạy lại cùng prompt trong môi trường staging. Nhóm ghi nhận mã HTTP, nội dung response và lỗi schema vào log trước khi nối sang workflow automation. Khi response đã ổn định về cấu trúc, họ mới chuyển các trường cần thiết sang workflow. Case này không chứng minh provider nào tốt hơn; nó chỉ cho thấy Codex có thể làm điểm kiểm tra giao thức trước khi một luồng tự động hóa phụ thuộc vào API đó.

Sao lưu file cấu hình trước khi đổi provider. Ví dụ với file `~/.codex/config.toml`, chạy `cp ~/.codex/config.toml ~/.codex/config.toml.bak` rồi kiểm tra biến môi trường bằng `printenv THIRD_PARTY_API_KEY`, thay vì ghi giá trị khóa trực tiếp vào TOML. `env_key` chỉ chứa tên biến, chẳng hạn `THIRD_PARTY_API_KEY`; nó không phải chuỗi `sk-…`. Có một điểm dễ gây nhầm giữa cấu hình Codex và lệnh kiểm tra độc lập. Trong file Codex, `base_url` cần có dạng ` để `wire_api = “responses”` tạo request đến ` Nếu muốn giữ đúng mẫu lệnh bên dưới, đặt `THIRD_PARTY_BASE_URL` là origin ` không thêm `/v1` lần thứ hai.

Kiểm tra request trước khi nối workflow Kiểm tra URL trước bằng `curl -i “$THIRD_PARTY_BASE_URL/v1″`; mã `404` ở đường dẫn gốc chưa đủ kết luận provider hỏng, vì nhiều dịch vụ chỉ mở endpoint cụ thể. Bài kiểm tra có giá trị hơn là gửi request hoàn chỉnh với model ID đã

được provider xác nhận:

export THIRD_PARTY_API_KEY="your-key"
export THIRD_PARTY_BASE_URL="" curl "$THIRD_PARTY_BASE_URL/v1/responses" \ -H "Authorization: Bearer $THIRD_PARTY_API_KEY" \ -H "Content-Type: application/json" \ -d '{"model":"confirmed-model-id","input":"Xin chào"}'

Đọc lỗi theo thứ tự: `401` thường liên quan khóa hoặc header, `404` thường liên quan URL hoặc model ID, còn HTTP `200` vẫn cần kiểm tra response có trường mà Codex mong đợi. Nếu request chạy được nhưng Codex lỗi, đối chiếu lại `wire_api = “responses”` và tránh giữ đồng thời các mục `model_provider` cùng `model_providers` nếu tài liệu provider không yêu cầu. Khi request độc lập đã trả về schema phù hợp, bạn có thể thử cùng luồng trong AI Studio Workflow bằng một node gọi HTTP trước khi đưa vào automation. Với RevidAPI, chỉ dùng các đường dẫn đã có trong tài liệu: LLM tương thích OpenAI là `POST /v1/chat/completions`, danh sách model là `GET /v1/chat/models`; không tự đổi chúng thành `/v1/responses`. Bạn cũng có thể nối workflow qua Hub Workflow n8n hoặc Import n8n JSON, nhưng cần kiểm tra lại header `x-api-key` và body của từng node trong dashboard RevidAPI.

Các lỗi cấu hình thường nằm ở ba giá trị cụ thể: `base_url` thiếu `/v1`, `env_key` bị điền bằng giá trị khóa, hoặc `wire_api` không phải `responses`. Năm câu hỏi sau giúp bạn rà đúng trường trước khi gửi request đầu tiên.

Base URL có cần `/v1` không?

Question: Base URL có cần `/v1` không? Answer: Có, nếu provider đặt Responses API dưới `/v1`; Codex

sẽ ghép thành endpoint hoàn chỉnh `/v1/responses`.

`env_key` là gì?

Question: `env_key` là gì? Answer: Đây là tên biến môi trường chứa API key, chẳng hạn `THIRD_PARTY_API_KEY`, không phải chuỗi khóa bắt đầu bằng giá trị bí mật.

Vì sao `wire_api` phải là `responses`?

Question: Vì sao `wire_api` phải là `responses`? Answer: Vì cấu hình này hướng Codex gọi trực tiếp `/v1/responses`, thay vì tự chuyển request sang giao thức Chat Completions.

Có dùng Chat Completions thay thế

được không? Question: Có dùng Chat Completions thay thế được không? Answer: Chỉ dùng khi tài liệu provider và cấu hình Codex xác nhận giao thức đó tương thích; tên model giống nhau chưa đủ kết luận.

Lỗi `401` và `404` nên kiểm tra gì?

Question: Lỗi `401` và `404` nên kiểm tra gì? Answer: Với `401`, kiểm tra API key và `env_key`; với `404`, kiểm tra `/v1`, model ID và endpoint Responses thực tế. Khi kiểm tra, hãy đối chiếu ba chuỗi riêng: tên biến trong `env_key`, giá trị model ID, và URL kết thúc bằng `/v1/responses`. Nếu provider có nhiều mục `model_provider` hoặc `model_providers`, cấu hình trộn lẫn có thể làm request đi sai endpoint và phát sinh `401` hoặc `404`. Hãng chưa công bố một quy tắc chung cho mọi provider, nên cần xác nhận Responses API trong tài liệu

của chính provider trước khi chọn `wire_api = “responses”`. Sau đó, bạn có thể kiểm tra API key, xác nhận giao thức và thử workflow phù hợp trên RevidAPI.

Khám phá workflow miễn phí tại AI Tạo ảnh & Video và lấy API key tại API Marketplace RevidAPI.

Tích hợp Veo 3.1 Omni với RevidAPI giúp tự động hóa TTS, lipsync và xuất video qua AI Studio. Developer có thể ghép n8n workflow với endpoint thật trên dashboard — phù hợp creator và startup Việt muốn scale sản xuất video AI mà không cần hạ tầng riêng.