Cách kết nối OpenAI API vào n8n là tạo một node `HTTP Request`, cấu hình `Header Auth` với `x-api-key`, rồi gửi JSON tới `/v1/chat/completions`. Bài viết này giúp bạn dựng request đầu tiên trong n8n, thay giá trị `model` và `messages` theo tài liệu của API, sau đó lấy nội dung trả về cho node kế tiếp. Bạn cũng sẽ biết cách đọc phần body khi request nhận HTTP `400`, vì mã trạng thái chỉ cho biết request bị từ chối chứ chưa chỉ ra lỗi nằm ở `model`, JSON hay header. Nhiều hướng dẫn trên SERP đi theo từng bước từ khái niệm đến cấu hình kết nối; phạm vi ở đây tập trung vào payload và cách kiểm tra phản hồi có thể dùng ngay trong workflow.

Tóm tắt nhanh

• Tạo `HTTP Request` với method `POST`, endpoint `/v1/chat/completions` và body JSON gồm `model`, `messages`.
• Đặt API key trong `Header Auth` dưới tên `x-api-key`, thay vì chèn trực tiếp vào nội dung prompt.
• Khi gặp `400`, mở response body trong execution của n8n để xem thông báo lỗi cụ thể trước khi sửa workflow.

Một API AI là điểm nhận request từ n8n và trả về kết quả do mô hình xử lý. Trong request, n8n thường gửi `messages` gồm `role` và `content`, còn response có thể chứa phần văn bản, mã lỗi hoặc metadata tùy endpoint. n8n đứng giữa các bước của workflow. Một `Webhook` hoặc `Form Trigger` có thể nhận dữ liệu, node gọi API chuyển dữ liệu đó thành JSON, rồi node sau đọc response để lưu vào Google Sheets, gửi email hoặc tạo nhánh xử lý. Vì vậy, kết nối API AI trong n8n không chỉ là nhập API key: dữ liệu đầu vào và trường response cũng phải khớp với node kế tiếp. Với API có schema riêng, `HTTP Request` thường phù hợp hơn node OpenAI chuyên dụng. Bạn có thể đặt method `POST`, URL endpoint và Header Auth với tên `x-api-key`, sau đó gửi body JSON tới `/v1/chat/completions`. Cách này cho phép kiểm soát rõ từng trường như `model`, `messages` và `Content-Type`; node chuyên dụng chỉ thuận tiện khi cấu hình của nhà cung cấp khớp với giao diện mà n8n hỗ trợ. Tên “tương thích OpenAI” chỉ mô tả cách gọi API, không bảo đảm mọi thứ giống OpenAI. Một endpoint có thể nhận `messages` nhưng yêu cầu model khác, giới hạn trường dữ liệu khác hoặc trả văn bản ở vị trí khác trong JSON. Chẳng hạn, expression đọc `choices[0].message.content` sẽ lỗi nếu nhà cung cấp trả kết quả ở `output.text`. Một request cơ bản có bốn phần cần kiểm tra: API key để xác thực, endpoint để xác định máy chủ nhận dữ liệu, method `POST` để gửi yêu cầu tạo kết quả, và JSON body để mô tả model cùng nội dung cần xử lý. Khi n8n nhận HTTP 400, hãy mở phần response body để đọc trường `error` hoặc thông báo chi tiết; chỉ nhìn mã 400 không cho biết bạn sai key, sai schema hay thiếu `messages`.

Phân biệt lớp kết nối và lớp xử lý API chỉ trả dữ liệu về n8n. Việc chọn trường nào, đổi tên dữ liệu và chuyển sang node tiếp theo vẫn thuộc workflow, ví dụ dùng expression `{{$json.messages}}` để lấy dữ liệu từ node trước hoặc trích nội dung trả về trước khi ghi vào database.

Một request gọi API AI trong n8n chỉ chạy đúng khi bốn phần khớp nhau: method `POST`, URL endpoint, header xác thực và JSON body. Chỉ cần đặt nhầm `/v1/chat/completions` thành `/v1/chat/completion`, node có thể trả `404` dù API key vẫn hợp lệ.

Kiểm tra các trường trước khi chạy

Schema không dùng chung Cùng nhận `model` và `messages` nhưng các API có thể yêu cầu tên trường, kiểu dữ liệu và cấu trúc response khác nhau. Payload dùng

được cho `/v1/chat/completions` chưa chắc chạy khi chuyển sang nhà cung cấp khác: `messages[].content` có thể phải là chuỗi, mảng block hoặc trường riêng. Vì vậy, khi HTTP Request trả `400`, bạn cần mở execution data trong n8n và đọc phần body, như `error.message`, `error.type` hoặc mã lỗi nhà cung cấp, thay vì chỉ kết luận rằng URL bị sai.

Khóa bí mật có nhiều chỗ để lộ Một API key đặt thẳng trong JSON body, expression hoặc node export có thể xuất hiện trong execution data và file workflow. Với Header Auth, hãy kiểm tra cả tên header, chẳng hạn `x-api-key`, và quyền xem execution trước khi chạy dữ liệu thật. Một lần bật lưu dữ liệu đầu vào và đầu ra để debug cũng có thể ghi lại prompt chứa thông tin khách hàng cùng response đầy đủ.

HTTP 200 chưa phải kết quả đạt API trả `200` chỉ cho biết request

được máy chủ xử lý thành công ở tầng HTTP. Response vẫn có thể thiếu trường nội dung, trả câu trả lời rỗng hoặc bỏ qua yêu cầu định dạng JSON. Trong n8n, nên kiểm tra expression lấy nội dung có tồn tại trước khi chuyển sang node lưu dữ liệu; nếu downstream cần `{{$json.choices[0].message.content}}`, cấu trúc đổi một cấp là workflow có thể lỗi.

Timeout và rate limit phải dựa vào tài liệu Không nên tự đặt retry cho mọi lỗi. `429` thường liên quan rate limit, còn `401` cần kiểm tra key; retry `401` chỉ lặp lại lỗi. Hãy đối chiếu timeout, số lần retry và header giới hạn request trong tài liệu API, rồi tạo nhánh xử lý lỗi riêng trong n8n.

Khi nên chọn cách khác Không nên gửi dữ liệu nhạy cảm như số căn cước hoặc nội dung hợp đồng nếu chưa có quy định lưu trữ, xóa dữ liệu và quyền truy cập rõ ràng. Workflow gọi API cũng không phù hợp với yêu cầu phản hồi tức thời khi n8n phải chờ timeout, hoặc với dịch vụ không công bố schema, giới hạn và định dạng lỗi.

Một shop online có thể nhận brief từ Google Forms, để n8n gửi nội dung đó qua HTTP Request tới API AI, rồi chuyển response sang bước biên tập hoặc lưu vào Google Sheets. Mô hình này phù hợp khi form đã có các trường cụ thể như `san_pham`, `doi_tuong`, `giong_dieu` và `kenh_dang`.

Tình huống một: từ brief đến nội dung marketing Ví dụ, nhân viên nhập brief cho chương trình bán áo mưa tại Đà Nẵng. Workflow có thể đi theo chuỗi `Form Trigger → Set → HTTP Request → Google Docs`. Trong body

của request, expression `{{$json.brief}}` đưa phần mô tả vào `messages`, còn các trường `doi_tuong` và `giong_dieu` được ghép thành yêu cầu riêng. Response trả về bản nháp; node Google Docs lưu nguyên văn để người phụ trách sửa tiêu đề, giá và thông tin giao hàng trước khi đăng. Cách này không biến API thành người duyệt nội dung. Bạn nên giữ một bước kiểm tra trước node gửi email, đăng mạng xã hội hoặc cập nhật trang sản phẩm. Với brief thiếu giá, khu vực giao hàng hoặc điều kiện khuyến mãi, workflow có thể dùng IF node để chuyển sang nhánh “cần bổ sung” thay vì gửi thẳng bản nháp cho khách.

Tình huống hai: xử lý email khách hàng Một doanh nghiệp nhận email qua Gmail Trigger có thể đưa `subject` và `textPlain` vào API để tạo ba trường: `summary`, `category` và `next_action`. Chẳng hạn, email “đổi size giày đơn hàng 4821”

được phân loại thành `doi_tra`, giữ lại mã `4821`, rồi chuyển sang Airtable hoặc CRM để nhân viên chăm sóc tiếp tục xử lý. Nên yêu cầu response dùng JSON với các khóa cố định và thêm IF node kiểm tra `category` trước khi định tuyến. Nhánh `khieu_nai` có thể gắn nhãn ưu tiên và chuyển người thật; nhánh `hoi_dap_thong_thuong` chỉ lưu bản tóm tắt. Khi API trả lỗi, hãy giữ item email gốc trong nhánh lỗi để không mất `messageId` và nội dung cần xem lại.

Mở rộng cho creator Creator có thể nối các bước dịch phụ đề, chuẩn hóa caption, tạo bản đọc TTS hoặc xử lý video vào cùng workflow. Một video mới trong Google Drive có thể kích hoạt bước lấy transcript, gửi phần văn bản cần dịch, rồi lưu kết quả vào Notion trước khi biên tập; mỗi bước nên ghi `fileId`, ngôn ngữ đích và trạng thái xử lý để lần chạy sau không dịch lại cùng một tệp.

Giữ API key ngoài expression Trong n8n, tạo một credential kiểu Header Auth cho node HTTP Request và đặt tên header là `x-api-key`; không chèn `YOUR_API_KEY` vào expression hoặc JSON body. Khi export workflow, credential

được tách khỏi cấu hình node, còn key có thể quản lý tại RevidAPI Dashboard. Với workflow chia sẻ cho team, kiểm tra cả Execution data vì request header có thể xuất hiện trong dữ liệu chạy nếu bạn bật lưu dữ liệu đầu vào.

Debug bằng payload nhỏ Hãy thử một request chỉ có model và một message ngắn trước khi đưa `{{$json.brief}}` vào body. RevidAPI dùng `POST https://revidapi.com/v1/chat/completions`; model hợp lệ và giá theo token xem bằng `GET https://revidapi.com/v1/chat/models`. Trong n8n, bật lưu raw response ở node thử nghiệm, rồi nối nhánh lỗi để ghi `statusCode`, body trả về và execution ID vào nơi bạn kiểm soát

được.

curl https://revidapi.com/v1/chat/completions \ -H "x-api-key: YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{"model":"claude-sonnet-5","messages":[{"role":"user","content":"Xin chào"}]}'

HTTP 400 chỉ nói request bị từ chối, chưa cho biết trường nào sai. Trong n8n, đọc phần body lỗi trước khi sửa expression: model không có trong danh sách, `messages` sai kiểu hoặc thiếu `x-api-key` là các điểm cần kiểm tra theo thứ tự. Một response HTTP 200 cũng nên được chuyển qua bước kiểm tra nội dung trước khi ghi vào Google Sheets, CRM hoặc gửi email.

Gọi cùng API ngoài n8n Nếu cần kiểm tra nhanh bằng Python, SDK OpenAI có thể trỏ vào base URL

của RevidAPI. Đoạn dưới đây dùng đúng endpoint chat và model `claude-sonnet-5`, nhưng bạn vẫn nên đối chiếu danh sách model trước khi đưa vào production.

from openai import OpenAI client = OpenAI(base_url="https://revidapi.com/v1", api_key="YOUR_API_KEY")
print(client.chat.completions.create( model="claude-sonnet-5", messages=[{"role": "user", "content": "Xin chào"}]
).choices[0].message.content)

Bạn có thể tham khảo workflow mẫu tại RevidAPI Workflow Hub hoặc import workflow từ n8n.revidapi.com, sau đó thay credential và model trước khi chạy. Với nhu cầu tạo ảnh hoặc video, hãy tra model từ endpoint danh mục tương ứng; không nên dùng body của chat completions cho các endpoint đó.

Cách kết nối OpenAI API vào n8n là gì?

Trong n8n, bạn tạo node HTTP Request, chọn `POST`, nhập endpoint `/v1/chat/completions`, thêm Header Auth với `x-api-key`, rồi gửi JSON gồm `model` và `messages`. Sau khi chạy node, lấy trường nội dung trong response để chuyển sang node lưu trữ, email hoặc bước xử lý tiếp theo.

Đặt `x-api-key` ở đâu trong n8n?

Trong node HTTP Request, mở Authentication, chọn Header Auth, sau đó tạo credential với tên header là `x-api-key` và giá trị là API key. Không đặt key vào `messages`, URL hoặc expression hiển thị trong dữ liệu đầu vào; hãy kiểm tra lại credential trước khi bấm Execute step.

Body `/v1/chat/completions` cần trường nào?

Payload tối thiểu thường có `model` và `messages`. Ví dụ trong n8n, phần JSON có thể dùng `{{$json.brief}}` để đưa brief từ node trước vào nội dung người dùng:

{ "model": "TEN_MODEL_THEO_TAI_LIEU", "messages": [ { "role": "user", "content": "{{$json.brief}}" } ]
}

Tên model và schema response phải lấy từ tài liệu của nhà cung cấp. API tương thích OpenAI có thể yêu cầu model khác dù vẫn dùng cùng đường dẫn `/v1/chat/completions`.

Vì sao HTTP Request trả lỗi 400?

HTTP 400 thường liên quan đến URL, JSON không hợp lệ, thiếu `model`, sai cấu trúc `messages` hoặc tên trường không

được hỗ trợ. Trong n8n, mở Output

của node và đọc phần response body để biết trường nào bị từ chối, thay vì chỉ nhìn dòng trạng thái `400`. Bạn cũng nên gửi một payload ngắn như một message `user` trước, rồi kiểm tra từng expression như `{{$json.brief}}`. Nếu request mẫu chạy được nhưng dữ liệu thật lỗi, nguyên nhân thường nằm ở giá trị đầu vào hoặc ký tự JSON chưa được xử lý.

Có thể dùng RevidAPI với n8n không?

Có. Bạn dùng HTTP Request node, đặt `x-api-key`, gửi `POST` tới `https://revidapi.com/v1/chat/completions` với body `model` và `messages`; danh sách model có thể kiểm tra bằng `GET https://revidapi.com/v1/chat/models`. API key lấy tại dashboard RevidAPI, còn response và lỗi vẫn cần

được kiểm tra trong Output của n8n.

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