Gọi API chat bằng Node.js: Hướng dẫn bắt đầu nhanh

Gọi API chat bằng Node.js là gửi HTTP request từ máy chủ tới dịch vụ chat, rồi xử lý phản hồi và lỗi; API key phải nằm ở máy chủ. Nếu bạn đang thêm ô chat tư vấn sản phẩm vào website bán hàng, gửi được một câu hỏi mới chỉ là điểm bắt đầu. Bạn còn cần biết phản hồi có đúng cấu trúc ứng dụng chờ nhận hay không, và giao diện sẽ hiển thị gì khi yêu cầu thất bại. Bài viết giúp bạn xác định loại API cần dùng, đi qua quy trình triển khai, kiểm thử và xem xét chi phí trước khi đưa tính năng chat vào sử dụng.

Tóm tắt nhanh

• Giữ API key trong môi trường máy chủ; mã JavaScript gửi xuống trình duyệt không phải nơi cất khóa.
• Đối chiếu method, payload và schema phản hồi với tài liệu trước khi viết phần xử lý dữ liệu.
• Thử cả phản hồi hợp lệ, dữ liệu rỗng và cấu hình sai; một lần gọi thành công chưa đủ để đánh giá luồng chat.

Đặt dịch vụ vào đúng luồng Với chat AI, luồng cơ bản là: người dùng → backend Node.js → dịch vụ chat → backend → giao diện. Backend gửi yêu cầu HTTP, nhận phản hồi và xử lý lỗi; API key giữ ở môi trường máy chủ. Nếu dùng Socket.IO để chuyển tin nhắn, bạn vẫn cần một dịch vụ riêng để sinh câu trả lời AI. Với ứng dụng Google Workspace, bạn có thể bắt đầu từ quickstart Google Chat cho Node.js. Mẫu dòng lệnh này liệt kê không gian trò chuyện theo tiêu chí lọc; phần chuẩn bị gồm bật API, cấu hình màn hình đồng ý OAuth, thông tin đăng nhập và ứng dụng Google Chat.

Giao diện nên nhận dữ liệu ổn định ngay cả khi bạn đổi dịch vụ chat. Chẳng hạn, backend có thể trả đối tượng nội bộ `{ reply, requestId }`, thay vì buộc frontend đọc cấu trúc phản hồi riêng của từng nhà cung cấp. Đây là cấu trúc bạn tự thiết kế, không phải schema mặc định của API.

Những phần bạn chủ động triển khai

Streaming và lịch sử cần hợp đồng riêng Muốn hiển thị câu trả lời từng phần, bạn phải xác nhận dịch vụ có hỗ trợ streaming và định dạng luồng nào. Backend cần đọc luồng đó rồi chuyển tiếp cho trình duyệt; việc Node.js đọc

được stream chưa chứng minh endpoint hỗ trợ tính năng này. Với lịch sử hội thoại, hãy kiểm tra mỗi yêu cầu phải gửi lại tin nhắn hay có thể dùng mã hội thoại do dịch vụ cấp. Nếu ứng dụng tự lưu lịch sử, bạn cần gắn từng cuộc trò chuyện với đúng tài khoản; đừng mặc định nhà cung cấp

sẽ lưu và khôi phục ngữ cảnh.

Trước khi nối khung chat vào giao diện, bạn nên chạy một lời gọi độc lập từ terminal với câu thử như “Trả lời bằng một câu tiếng Việt”. Cách này cho phép kiểm tra cấu hình và dữ liệu trả về trước khi thêm trạng thái chờ hay nút gửi.

Hoàn tất đầu ra

của từng bước Làm lần lượt theo bảng. Chỉ chuyển bước khi bạn đã kiểm tra được đầu ra ở cột cuối.

Kiểm tra đúng trường dữ liệu Ở bước 5, hãy thêm một phản hồi JSON thiếu trường chứa câu trả lời. Kiểm tra script phát hiện sai schema thay vì đưa `undefined` ra giao diện. Phân biệt ca này với trường tồn tại nhưng chứa chuỗi rỗng: bạn cần biết mình đọc sai cấu trúc hay thực sự nhận nội dung rỗng.

Một câu trả lời xác nhận sai chính sách hoàn tiền vẫn có thể đi kèm HTTP thành công. Với nội dung ảnh hưởng đến tiền hoặc cam kết với khách, bạn nên giữ bước nhân viên duyệt trước khi gửi; parse JSON thành công chỉ xác nhận dữ liệu đọc được, không xác nhận câu trả lời đúng.

Phân biệt lỗi trước khi retry Với `fetch`, phản hồi HTTP báo lỗi không tự làm Promise bị reject. Bạn cần phân biệt ba trường hợp để tránh retry mọi lỗi:

• Mạng: `fetch` bị reject, chưa có phản hồi HTTP — Kiểm tra kết nối và nguyên nhân trước khi gửi lại
• HTTP: Có phản hồi nhưng `response.ok` là `false` — Đối chiếu tài liệu nhà cung cấp để quyết định retry
• Parse JSON: `response.json()` thất bại — Kiểm tra `Content-Type` và định dạng body Timeout phía Node.js không chứng minh dịch vụ chưa xử lý yêu cầu. Gửi lại có thể tạo lượt xử lý trùng; hãy xác nhận chính sách tính phí và cơ chế chống trùng của nhà cung cấp trước khi bật retry tự động.

Chưa rõ giá hoặc dữ liệu thì hoãn triển khai Chưa có dữ liệu giá đã xác nhận cho dịch vụ bạn chọn nên chưa thể báo chi phí. Hãy xác định đơn vị tính phí thực tế: token, lượt gọi hay đơn vị khác; kiểm tra cả phí cho lượt lỗi và retry. Nếu chưa kiểm soát

được dữ liệu gửi đi, đừng tự động chuyển toàn bộ hội thoại khách hàng. Loại API key, số điện thoại và địa chỉ khỏi log; chỉ ghi trường phục vụ chẩn đoán như thời điểm, mã trạng thái và mã yêu cầu nếu có.

Shop nhận câu hỏi về đổi size; creator nhận bình luận về công dụng sản phẩm. Đây là hai tình huống minh họa cho backend Node.js tạo bản nháp, không phải case study đã đo lường.

Cửa hàng: soạn câu trả lời từ thông tin đã duyệt Bạn đưa vào câu hỏi “Áo này còn size M không, mặc chật có đổi

được không?” cùng mã sản phẩm, tồn kho và chính sách đổi hàng đã duyệt. Backend gửi các dữ kiện này để tạo bản nháp cho nhân viên chăm sóc khách hàng. Đầu ra cần trả lời riêng chuyện còn hàng và điều kiện đổi size. Nếu thiếu tồn kho, bản nháp phải ghi cần kiểm tra, không tự khẳng định “còn hàng”. Nhân viên đối chiếu hệ thống bán hàng trước khi gửi khách. Điều kiện nghiệm thu: đúng mã áo, đúng chính sách đổi, giữ dấu tiếng Việt và không tự thêm cam kết. Bạn nên thử cả câu không dấu như “doi size duoc ko” và câu thiếu mã sản phẩm.

Creator: phản hồi bình luận theo nguyên tắc thương hiệu Đầu vào gồm bình luận “Da nhạy cảm dùng

được không?”, nội dung bài đăng và nguyên tắc thương hiệu: xưng “mình–bạn”, không khẳng định công dụng chưa được duyệt. Backend tạo phản hồi nháp; marketer chịu trách nhiệm duyệt giọng điệu và dữ kiện. Với câu hỏi vượt tài liệu sản phẩm, đầu ra cần đề xuất chuyển người phụ trách. Nghiệm thu bằng cách kiểm tra phản hồi có bám tài liệu, đúng cách xưng hô và nhận diện câu ngoài phạm vi hay không. Ở cả hai luồng, lưu mã lượt thử, phiên bản tài liệu, bản nháp và quyết định duyệt. Chỉ công bố kết quả khi có log cùng tiêu chí đánh giá; chưa có dữ liệu thì chưa kết luận về tỷ lệ trả lời đúng.

Brief đã cung cấp cấu hình cụ thể: `POST https://revidapi.com/v1/chat/completions`, header `x-api-key`, body gồm `model` và `messages`. Hai mẫu sau bám cấu hình đó; chúng tôi chưa gọi thử endpoint để kiểm chứng phản hồi thực tế. Trước khi triển khai, bạn cần đối chiếu schema trong tài liệu trên Dashboard RevidAPI.

Mẫu gọi tối giản, tách khỏi giao diện Lấy key tại dashboard và đặt vào biến môi trường `REVIDAPI_KEY`

của máy chủ. Hàm `callChat` chỉ nhận nội dung và tùy chọn `signal`, nên bạn có thể kiểm thử riêng mà không cần mở giao diện chat.

async function callChat(content, { signal } = {}) { const response = await fetch( "https://revidapi.com/v1/chat/completions", { method: "POST", headers: { "x-api-key": process.env.REVIDAPI_KEY, "Content-Type": "application/json" }, body: JSON.stringify({ model: "claude-sonnet-5", messages: [{ role: "user", content }] }), signal } ); if (!response.ok) { throw new Error(`HTTP ${response.status}`); } return response.json();
}

Mẫu trả về JSON nguyên bản. Với schema tương thích OpenAI được brief mô tả, nội dung nằm ở `choices[0].message.content`; hãy kiểm tra trường này trước khi chuyển câu trả lời về giao diện. Không suy ra khả năng streaming chỉ từ đường dẫn `/chat/completions`.

Thêm hủy yêu cầu và bắt lỗi Biến thể sau dùng lại `callChat`, thêm `AbortController` và `try/catch`. Mốc `15_000` mili giây là ví dụ do ứng dụng tự chọn, không phải timeout chính thức

của dịch vụ.

async function chatWithTimeout(content) { const controller = new AbortController(); const timer = setTimeout(() => controller.abort(), 15_000); try { const data = await callChat(content, { signal: controller.signal }); const text = data.choices?.[0]?.message?.content; throw new Error("Phản hồi thiếu nội dung chat"); } return text; } catch (error) { if (controller.signal.aborted) { throw new Error("Đã hết thời gian chờ phản hồi"); } throw error; } finally { clearTimeout(timer); }
}

Bạn có thể kiểm thử hàm bằng phản hồi giả có `choices: []` để xác nhận nhánh thiếu nội dung. Việc tách hàm hữu ích ngay khi thay giao diện web bằng tác vụ chạy nền: cấu hình request vẫn ở một chỗ. Chi phí chat tính theo token; tra model và giá qua `GET https://revidapi.com/v1/chat/models`, chưa có số credit cụ thể trong brief. Khi cần đưa lời gọi này vào workflow, xem hub workflow n8n, rồi đối chiếu lại method, header và body của bước HTTP.

Có bắt buộc dùng SDK để tích hợp API chat không?

Không, trừ khi nhà cung cấp yêu cầu SDK. Nếu dịch vụ công bố giao diện HTTP, bạn có thể gọi bằng `fetch` hoặc Axios. Cân nhắc SDK khi kiểu dữ liệu và các hàm hỗ trợ

của nó phù hợp với dự án.

Khi nào nên chọn fetch, khi nào cân nhắc Axios?

Chọn `fetch` nếu phiên bản Node.js đang chạy có hỗ trợ và bạn muốn giảm phụ thuộc. Cân nhắc Axios khi dự án đã dùng interceptor cho HTTP client. Với `fetch`, bạn cần kiểm tra `response.ok` để phát hiện trạng thái HTTP lỗi.

Có thể dùng mock khi chưa gọi dịch vụ thật không?

Có. Bạn nên tạo mock theo hợp đồng API: đúng status, header và cấu trúc JSON mà ứng dụng sử dụng. Chẳng hạn, dùng `node:test` để kiểm tra lớp tích hợp với phản hồi giả; mock chưa chứng minh dịch vụ thật hoạt động đúng.

Làm sao thay nhà cung cấp mà giảm sửa mã ứng dụng?

Bạn có thể đặt lời gọi trong adapter, cung cấp hàm chung như `sendMessage(messages)`. Mỗi adapter chuyển đầu vào và phản hồi theo hợp đồng riêng. Khi đổi nhà cung cấp, kiểm tra các trường ứng dụng cần, chẳng hạn nội dung và lý do kết thúc.

Cần kiểm tra gì trước khi nâng phiên bản thư viện HTTP?

Đọc changelog và yêu cầu phiên bản Node.js; kiểm tra thay đổi ESM/CommonJS, timeout và kiểu lỗi. Sau khi nâng Axios hoặc thư viện liên quan, chạy lại kiểm thử adapter với mock và một lời gọi thật trong môi trường thử nghiệm.

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