Lỗi AI API 401 thường bắt đầu từ khóa hoặc header xác thực; 404 cần kiểm tra `/v1`, endpoint và model, còn 400 và 402 phải đọc response body trước khi sửa. Một request chạy được hôm qua nhưng hôm nay trả 401 không có nghĩa model đã ngừng hoạt động: khóa có thể bị thay, hoặc header `x-api-key` chưa được gửi từ môi trường chạy hiện tại. Với 404, cũng đừng vội đổi model khi URL đang thiếu `/v1`. Hai lỗi này dễ bị nhầm nếu bạn chỉ nhìn thông báo chung trên màn hình workflow. Bài viết này giúp bạn dùng `curl` để thử riêng request đang lỗi, xem mã HTTP cùng response body, rồi quyết định nên sửa cấu hình, kiểm tra quyền dùng model hay xem lại credit. Bạn sẽ có cách đối chiếu trước khi chạy lại cả loạt tác vụ; riêng 400 có thể do payload không hợp lệ, nên gửi lại y nguyên thường không giải quyết được gì.

Tóm tắt nhanh

• `401`: đối chiếu khóa và tên header xác thực, chẳng hạn `x-api-key`.
• `404`: kiểm tra URL có đúng `/v1`, đúng endpoint và đúng model ID.
• `400` hoặc `402`: đọc response body trước khi kiểm tra payload, quyền dùng model hoặc credit.

Một request gọi model thất bại không cho bạn biết ngay phải sửa khóa hay sửa URL. Trước khi đổi cấu hình, hãy nhìn hai phần của phản hồi: HTTP status và response body. Status là mã máy chủ trả về cho *request cụ thể* đó; body có thể chứa thông báo giải thích vì sao request bị từ chối. Chẳng hạn, thấy `401` thì kiểm tra xác thực, nhưng chỉ mã `401` không cho biết khóa bị thiếu, sai hay được gửi bằng tên header không đúng.

Đọc mã, rồi đọc thông báo Với `404`, hãy giữ nguyên URL đã gọi để đối chiếu đường dẫn `/v1`, endpoint và model ID. Nhưng đừng mặc định mọi `404` đều do thiếu `/v1`: tên model sai cũng có thể dẫn tới mã này. Tương tự, `400` có thể liên quan đến payload hoặc quyền dùng model; `402` có thể liên quan đến credit. Thông báo trong body mới là đầu mối để chọn thứ cần kiểm tra tiếp, không phải lý do để gửi lại nguyên request nhiều lần. Khi xem log, ghi status và body

của cùng một request cạnh nhau. Ví dụ, dòng log chỉ có `404` nhưng không lưu thông báo lỗi sẽ khiến bạn phải đoán giữa URL và model. Ngược lại, nếu body nói rõ trường `model` không hợp lệ, bạn có điểm bắt đầu cụ thể hơn việc sửa toàn bộ cấu hình. Body không phải lúc nào cũng có cấu trúc giống nhau giữa các dịch vụ, nên đọc nội dung thực tế thay vì giả định luôn có một trường `message`. Nếu phản hồi có request ID, ghi lại cả giá trị đó, thời điểm gọi và URL đã che tham số nhạy cảm. Request ID đôi khi nằm trong response header, đôi khi trong body; tên trường phụ thuộc nhà cung cấp. Khi cần gửi báo lỗi cho đội hỗ trợ, cặp status–body cùng request ID giúp họ tra đúng lần gọi mà không cần bạn chia sẻ API key.

Một request báo 404 chưa đủ để kết luận thiếu `/v1`: path có thể đúng nhưng model ID không tồn tại trên dịch vụ bạn đang gọi. Hãy chuẩn bị một request đối chứng với `API_URL` là URL đầy đủ theo tài liệu nhà cung cấp, `API_KEY` thuộc tài khoản của bạn và `BODY` là JSON hợp lệ dùng model tài khoản được phép gọi. Các phép thử bên dưới kiểm tra giả thuyết, không bảo đảm tạo ra đúng mã lỗi ghi ở từng hàng.

Đối chiếu phản hồi với từng giả thuyết

Đừng sửa đồng thời URL, khóa và model khi workflow báo 404: lần thử tiếp theo dù chạy được cũng không cho bạn biết thay đổi nào có tác dụng. Hãy lấy đúng một request thất bại làm mốc, rồi kiểm tra theo thứ tự sau. 1. Lưu mẫu lỗi. Trong log của HTTP Request, ghi thời điểm, URL thực tế, method, status và response body; giữ request ID nếu máy chủ trả về. Trước khi đưa mẫu vào ticket hoặc nhóm chat, che giá trị khóa, token và dữ liệu người dùng trong body. Giữ bản gốc ở nơi có quyền truy cập phù hợp để đối chiếu các lần thử.

1. Kiểm tra đường dẫn. Đọc URL đã được ứng dụng ghép xong, không chỉ biến `BASE_URL` trong cấu hình. Đối chiếu từng đoạn path, nhất là `/v1` và tên endpoint, với tài liệu của nhà cung cấp đang gọi. Nếu URL sai, chỉ sửa nhóm cấu hình URL rồi thử lại; 404 chưa đủ để kết luận lỗi nằm ở đoạn nào.
2. Kiểm tra xác thực. Với 401, mở cấu hình credentials hoặc node HTTP Request để xem header có thực sự được gửi hay không. Đối chiếu tên header `x-api-key` với yêu cầu của dịch vụ; nếu dịch vụ dùng `Authorization: Bearer`, đừng tự đổi sang `x-api-key`. Kiểm tra khóa đang nạp vào môi trường chạy, tránh kết luận dựa trên khóa trong máy cá nhân.
3. Đối chiếu body. So `model` và cấu trúc payload của mẫu lỗi với mẫu request được tài liệu hỗ trợ. Với 404, kiểm tra model ID sau khi đã xác nhận path; với 400, đọc thông báo trong body để phân biệt payload sai với model tài khoản chưa được phép dùng. Chỉ đổi nhóm cấu hình model hoặc payload trong lần thử này, và ghi rõ giá trị nào đã đổi.
4. Kiểm tra tài khoản. Nếu body báo 402 hoặc nhắc tới quyền dùng model, vào dashboard của đúng tài khoản gắn với khóa đang chạy để xem credit và quyền truy cập. Đừng coi việc tạo khóa mới là cách xác nhận số dư. Ghi lại trạng thái tài khoản cùng thời điểm thử để người khác có thể đối chiếu.
5. Thử riêng rồi mới chạy lại workflow. Dùng lệnh `curl` ở phần bảng chẩn đoán với URL, header và payload đã đối chiếu; gửi một request nhỏ, tách khỏi job hàng loạt. Lưu status và body mới cạnh mẫu ban đầu. Chỉ khôi phục workflow khi phép thử trả kết quả mong đợi và cùng cấu hình đó đã được cập nhật trong ứng dụng; nếu chưa, tiếp tục đổi một nhóm cấu hình mỗi lần.

Một mã `401` không tự chứng minh khóa API đã hết hạn. Có dịch vụ yêu cầu `x-api-key`, có dịch vụ nhận `Authorization: Bearer`; gửi đúng khóa vào sai header vẫn có thể bị từ chối. Khi đối chiếu thông báo lỗi, hãy dùng quy ước của dịch vụ đang gọi, không lấy cấu hình từ một API khác áp sang.

Phản hồi có thể không đến từ nơi bạn nghĩ Nếu ứng dụng gọi qua proxy

của công ty hoặc API gateway, mã `404` bạn thấy có thể do lớp trung gian không nhận ra route, dù endpoint phía sau vẫn tồn tại. So sánh URL trong log ứng dụng với URL thực tế proxy chuyển tiếp, nhất là phần `/v1`. Xem cả response body và header phản hồi để tìm dấu hiệu nguồn trả lỗi; chỉ riêng status không xác định được lớp nào đã trả lời. Tương tự, `400` không mặc nhiên là model không được bán: payload sai cũng có thể bị từ chối. `402` gợi ý vấn đề thanh toán hoặc credit, nhưng cách dùng mã này tùy dịch vụ. Đọc thông báo trong body rồi mới quyết định cần sửa trường `model`, kiểm tra quyền dùng model hay xem số dư tài khoản.

Thử lại cũng có chi phí Đừng gửi lại nguyên request tạo ảnh hoặc gọi LLM hàng chục lần khi chưa đọc body: nếu bạn sửa đúng cấu hình và request bắt đầu thành công, các lần gọi tiếp theo có thể bị tính phí. Hãy dừng tác vụ tự retry, chọn một request với đầu vào ngắn để kiểm tra, rồi chỉ bật lại luồng xử lý

sau khi biết lần gọi nào đã được chấp nhận. Chúng tôi chưa biết mức phí cụ thể của dịch vụ bạn dùng; kiểm tra bảng giá và lịch sử sử dụng của chính tài khoản đó.

Hai tình huống sau là giả định. Chúng cho thấy vì sao cùng một workflow tạo nội dung cần cách xử lý khác nhau khi node HTTP Request báo 401 và khi cả loạt yêu cầu của chiến dịch bắt đầu thất bại.

Creator: workflow n8n dừng ở HTTP Request Một creator ở Hà Nội dùng n8n để lấy nội dung từ biểu mẫu rồi gửi yêu cầu viết bản nháp bài đăng. Node HTTP Request trả 401. Bạn mở lần chạy lỗi, lưu status và response body, nhưng che khóa API, dữ liệu khách hàng trước khi gửi ảnh chụp hoặc log cho người khác. Trong cấu hình node, xem khóa có

được truyền qua đúng header mà nhà cung cấp yêu cầu không; chẳng hạn, nếu tài liệu ghi `x-api-key`, đừng nhập khóa vào một header tự đặt tên. Sau đó, dùng `curl -i -sS` gửi một yêu cầu nhỏ đến đúng URL đang cấu hình trong node, với khóa lấy từ cùng tài khoản. Nếu curl chạy được còn n8n vẫn báo 401, hãy kiểm tra credential được gắn vào node và giá trị header thực tế. Nếu phản hồi là 404, đối chiếu URL đầy đủ, đoạn `/v1` nếu tài liệu có yêu cầu, và model ID trong body. Chỉ chạy lại workflow với một bản nháp

sau khi sửa; đừng cho chạy lại cả hàng đợi khi chưa thấy phản hồi hợp lệ.

Marketer: nhiều yêu cầu trong một chiến dịch cùng lỗi Một marketer chuẩn bị nội dung cho nhiều mẫu quảng cáo

của shop online, rồi thấy các yêu cầu tạo bản nháp liên tiếp thất bại. Việc đầu tiên là tạm dừng lượt chạy kế tiếp, giữ lại một response body đã che thông tin nhạy cảm và thử một yêu cầu ngắn từ chính tài khoản đang chạy chiến dịch. Cách này giới hạn số request phát sinh trong lúc chưa rõ nguyên nhân; yêu cầu thử vẫn có thể tính phí. Nếu body báo 402 và nhắc đến credit, bạn kiểm tra số dư tài khoản trước khi mở lại lượt chạy. Nếu là 400, đọc trường báo lỗi để xem payload sai hay model chưa được phép sử dụng; không gửi lại nguyên loạt request. Trường hợp báo 401 hoặc 404, quay về kiểm tra khóa, header, URL và model của cấu hình chiến dịch. Chỉ tiếp tục với cả danh sách quảng cáo

sau khi một request nhỏ dùng cùng cấu hình đã nhận phản hồi đúng.

Khi request tới RevidAPI trả 401, hãy kiểm tra khóa và header `x-api-key` trước khi sửa payload. Bạn có thể xem khóa và credit tại dashboard RevidAPI; đừng dán khóa vào ticket, ảnh chụp lỗi hoặc lệnh được lưu trong mã nguồn.

Gửi một request để đối chiếu Trong terminal Bash, nhập khóa bằng `read -rs` để ký tự không hiện trên màn hình. Sau đó lấy model ID từ `GET /v1/chat/models`, đối chiếu với tài liệu API và nhập đúng ID vào `REVID_MODEL_ID`. Không tự đặt một tên model để thử 404: lỗi có thể đến từ cả đường dẫn lẫn quyền dùng model.

read -rs -p 'API key: ' REVID_API_KEY
printf '\n'
curl -i -sS 'https://revidapi.com/v1/chat/models' \ -H "x-api-key: $REVID_API_KEY"
read -r -p 'Model ID trong danh sách: ' REVID_MODEL_ID
curl -i -sS 'https://revidapi.com/v1/chat/completions' \ -H "x-api-key: $REVID_API_KEY" \ -H 'Content-Type: application/json' \ -d "{\"model\":\"$REVID_MODEL_ID\",\"messages\":[{\"role\":\"user\",\"content\":\"Xin chào\"}]}"

Lệnh trên dùng `-i` để hiện status và response body, không dùng `-v` hay `–trace` vì các chế độ đó có thể in header chứa khóa. Trước khi chia sẻ kết quả terminal, vẫn cần kiểm tra và che thông tin nhạy cảm trong body. Một lần gọi chat có thể phát sinh phí; giá theo model cần xem tại `GET /v1/chat/models`. Nếu nhận 401, đối chiếu giá trị khóa trên dashboard và xác nhận ứng dụng đang gửi đúng `x-api-key`; đừng gửi nguyên header cho người hỗ trợ. Với 404, so URL thực tế với `/v1/chat/completions` và kiểm tra model ID vừa chọn. Không thể kết luận thiếu `/v1` chỉ từ status 404. Với 400, đọc body để phân biệt payload sai với model không

được bán hoặc không được phép dùng; kiểm tra lại `messages`, `model` và danh sách model trước khi gửi tiếp. Với 402, đọc body rồi kiểm tra credit trên dashboard. Nếu curl chạy được nhưng ứng dụng vẫn lỗi, so request ứng dụng với lệnh vừa chạy, nhất là URL, header và model ID; tuyệt đối không bật log ghi nguyên header xác thực.

Nếu xuất bản dữ liệu có cấu trúc FAQPage, dùng từng tiêu đề câu hỏi dưới đây làm `Question.name` và câu trả lời ngay sau làm `acceptedAnswer.text`. Đừng đưa API key vào phần dữ liệu công khai.

Có nên gửi toàn bộ log cho bộ phận hỗ trợ?

Không. Che API key, token, nội dung người dùng và header xác thực trước khi gửi; giữ lại status và request ID nếu có.

Sửa cấu hình xong có nên chạy lại cả workflow?

Chưa. Gửi một request nhỏ với cùng endpoint và model trước; chỉ chạy lại hàng loạt khi phản hồi đã đúng.

Làm sao biết lỗi nằm ở API hay workflow?

Gửi cùng request bằng `curl`, rồi so status và response body với node đang lỗi. Khác biệt có thể nằm ở cấu hình node.

Khi nào cần liên hệ hỗ trợ?

Khi request đúng tài liệu vẫn lỗi, gửi status, response body đã che dữ liệu, thời điểm và request ID nếu phản hồi có cung cấp.

Gặp 401, 404, 400 hoặc 402 thì kiểm tra gì trước?

401: kiểm tra `x-api-key`; 404: đối chiếu `/v1`, endpoint, model; 400: đọc body, kiểm tra payload hoặc quyền model; 402: kiểm tra credit. Trước lần thử tiếp theo, kiểm tra lại URL có `/v1` khi tài liệu yêu cầu, thông tin xác thực và payload `model`. Mở dashboard để xác nhận trạng thái tài khoản.

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