Chuyển đến nội dung chính

Documentation Index

Fetch the complete documentation index at: https://apidoc.cometapi.com/llms.txt

Use this file to discover all available pages before exploring further.

Việc xử lý lỗi CometAPI sẽ dễ dàng nhất khi bạn tách riêng các vấn đề về cấu trúc request, vấn đề xác thực, lỗi path, và các lỗi nền tảng có thể thử lại. Hãy dùng kết hợp trạng thái HTTP, error.code, và error.message để quyết định nên sửa request hay thử lại.

Phân loại nhanh

StatusThường có nghĩa là gìRetry?Hành động đầu tiên
400Xác thực request thất bại trước khi request được xử lý bình thường.KhôngXác thực model, messages, cấu trúc JSON và kiểu dữ liệu của các trường.
401API key bị thiếu, sai định dạng hoặc không hợp lệ.KhôngKiểm tra Authorization: Bearer <COMETAPI_KEY>.
403Quyền truy cập bị chặn hoặc request hiện tại không được phép.Thường là khôngThử lại bằng một request chuẩn đã biết hoạt động và trước tiên hãy bỏ các trường dành riêng cho model.
Path mistakeBase URL sai hoặc path endpoint sai. Trên Comet, điều này có thể hiển thị dưới dạng chuyển hướng 301 hoặc HTML, thay vì JSON 404 rõ ràng.KhôngDùng chính xác https://api.cometapi.com/v1 và tắt tự động theo dõi chuyển hướng khi debug.
429Giới hạn tốc độ hoặc quá tải tạm thời.Dùng exponential backoff với jitter.
500 with error.code: invalid_requestMột request bị lỗi định dạng xuất hiện dưới dạng phản hồi trạng thái server.KhôngSửa phần thân request trước khi thử lại.
500, 503, 504, 524Lỗi nền tảng, nhà cung cấp hoặc lỗi thuộc nhóm timeout.Thử lại với backoff và giữ lại request id.

Error envelope

Nhiều lỗi CometAPI sử dụng phần thân lỗi như sau:
{
	"error": {
		"message": "...",
		"type": "comet_api_error",
		"param": "",
		"code": "invalid_request"
	}
}
Một số phản hồi để trống code. Khi trạng thái là 500, hãy xem error.codeerror.message là tín hiệu quyết định.

400 Bad Request

400 thường có nghĩa là phần thân request không vượt qua xác thực trước khi request có thể được xử lý bình thường. Các nguyên nhân phổ biến:
  • Thiếu các trường bắt buộc như model
  • Cấu trúc JSON không hợp lệ
  • Gửi một trường với kiểu dữ liệu sai
  • Tái sử dụng các tham số dành riêng cho nhà cung cấp mà endpoint đã chọn không chấp nhận
Hãy bắt đầu từ một request tối thiểu đã biết là hoạt động, sau đó thêm lại từng trường tùy chọn một. So sánh payload với schema của endpoint trong tài liệu API reference. Dùng một request tối thiểu như sau:
{
	"model": "your-model-id",
	"messages": [
		{
			"role": "user",
			"content": "Hello"
		}
	]
}
Thay your-model-id bằng bất kỳ model ID hiện tại nào từ trang CometAPI Models. Đừng cho rằng mọi request chat lỗi định dạng đều trả về 400. Việc thiếu các trường chat bắt buộc như messages cũng có thể xuất hiện dưới dạng 500 với error.code: invalid_request.

500 Internal Server Error

Hầu hết phản hồi 500 cho thấy lỗi nền tảng hoặc lỗi từ nhà cung cấp. Với Chat Completions, một số request lỗi định dạng cũng có thể xuất hiện dưới dạng 500 nhưng vẫn mang error.code: invalid_request. Một ví dụ là request bỏ qua messages:
{
	"error": {
		"message": "field messages is required (request id: ...)",
		"type": "comet_api_error",
		"param": "",
		"code": "invalid_request"
	}
}
Nếu phản hồi 500error.code: invalid_request, hãy coi đó là vấn đề của request:
  1. Sửa phần thân request.
  2. So sánh payload với schema của endpoint.
  3. Chỉ thử lại sau khi đã sửa payload.
Nếu phản hồi 500 không cho thấy đó là request không hợp lệ, hãy giữ lại request id và dùng backoff.

401 Invalid Token

Lỗi token thường trông như sau:
{
	"error": {
		"code": "",
		"message": "invalid token (request id: ...)",
		"type": "comet_api_error"
	}
}
Những điều cần kiểm tra:
  1. Header phải chính xác là Authorization: Bearer <COMETAPI_KEY>.
  2. Đảm bảo ứng dụng của bạn không tải một key cũ từ .env, lịch sử shell hoặc kho lưu trữ secret đã triển khai.
  3. Nếu một key lỗi và một key khác hoạt động với cùng request đó, hãy xem đây là vấn đề về token, không phải vấn đề về endpoint.

403 Forbidden

403 thường là một trong các tình huống sau:
  • Request bị chặn bởi một quy tắc phía nền tảng như lọc WAF
  • Token hoặc route không được phép sử dụng model hoặc dạng request được yêu cầu
  • Model được chọn từ chối một trong các tham số nâng cao mà bạn đã truyền vào
Việc nên làm trước tiên:
  1. Thử lại với một request văn bản rất đơn giản trên một model đã biết là hoạt động tốt.
  2. Gỡ các trường nâng cao và tham số đặc thù của nhà cung cấp, sau đó thêm lại dần dần.
  3. Nếu response bao gồm request id, hãy giữ lại nó trước khi liên hệ hỗ trợ.
Nếu thông báo nhắc đến các thuật ngữ nội bộ như group hoặc channel, hãy xem chúng là chi tiết định tuyến, không phải thứ đầu tiên cần chẩn đoán từ phía client. Cách khắc phục thực tế vẫn là xác thực token, model và dạng request trước.

Sai base URL hoặc sai path

Trên Comet, lỗi path có thể biểu hiện thành:
  • Một chuyển hướng
  • Một response HTML không phải JSON nếu client của bạn theo chuyển hướng
  • Một lỗi phân tích cú pháp bên trong SDK của bạn
  • Một request không bao giờ đến được tầng API một cách hoàn chỉnh
Hãy dùng chính xác base URL này:
https://api.cometapi.com/v1
Các bước kiểm tra được khuyến nghị:
  1. Xác nhận base URL có bao gồm /v1.
  2. Xác nhận endpoint path khớp chính xác với tài liệu.
  3. Tắt tự động theo chuyển hướng trong khi gỡ lỗi các vấn đề về path.

413 Request Entity Too Large

Nếu bạn thấy 413, trước tiên hãy xem đó là vấn đề về kích thước request. Những nguyên nhân phổ biến gồm:
  • Payload base64 lớn
  • Hình ảnh hoặc âm thanh quá lớn được nhúng inline
  • Body multipart hoặc JSON rất lớn
Việc cần làm:
  1. Giảm kích thước hoặc nén nội dung đính kèm.
  2. Chia các tác vụ lớn thành các request nhỏ hơn.
  3. Đừng cho rằng độ dài văn bản thuần là nguyên nhân duy nhất.

429 Too Many Requests

Hãy xem 429 là lỗi có thể thử lại:
  1. Sử dụng exponential backoff với jitter.
  2. Giảm mức độ đồng thời của các đợt gửi dồn dập.
  3. Bật ghi log request để bạn có thể thấy route và model nào đang bão hòa trước.
Để xem một mẫu retry có thể tái sử dụng, hãy xem ví dụ backoff trong Chat Completions.

503, 504, và 524

Các mã trạng thái này là lỗi phía máy chủ hoặc thuộc nhóm lỗi timeout. Hướng dẫn thực tế:
  • 503: route hoặc dịch vụ nhà cung cấp tạm thời không khả dụng
  • 504524: lỗi thuộc nhóm timeout giữa nền tảng, edge hoặc dịch vụ nhà cung cấp
Việc cần làm:
  1. Thử lại với backoff.
  2. Giữ lại request id, endpoint, model và dấu thời gian.
  3. Nếu cùng một lỗi lặp lại qua nhiều lần thử lại, hãy liên hệ hỗ trợ kèm theo ngữ cảnh đó.

Trước khi bạn liên hệ bộ phận hỗ trợ

Trước tiên, hãy thu thập các chi tiết sau:
  • Phương thức HTTP
  • Đường dẫn endpoint
  • Model ID
  • Request body JSON đã được làm sạch (đây là mục hữu ích nhất cho hầu hết các lệnh gọi API)
  • Query parameters nếu request bị lỗi có sử dụng chúng
  • Response body chính xác nếu client của bạn đã ghi nhận được
  • HTTP status đầy đủ
  • error.message chính xác
  • Bất kỳ request id nào
  • Dấu thời gian gần đúng
  • Liệu cùng một request đó có hoạt động với model khác hoặc token khác hay không
Nếu route bị lỗi chấp nhận tải tệp lên (chỉnh sửa hình ảnh, tải lên âm thanh, tạo video, v.v.) thay vì request body JSON thuần, hãy gửi payload đã được gửi tương ứng:
  • Tên các trường và giá trị văn bản bạn đã gửi cùng với tệp
  • Tên tệp, loại tệp và kích thước tệp ước lượng
  • Liệu tệp được tải lên trực tiếp, được tham chiếu bằng URL hay được nhúng dưới dạng base64
Cách hiệu quả nhất để tái hiện lỗi là payload request đã được làm sạch chính xác. Với hầu hết các lệnh gọi API, điều đó có nghĩa là raw request body JSON. Với các route tải tệp lên, điều đó có nghĩa là danh sách trường cộng với metadata của tệp.
Điều này giúp rút ngắn đáng kể thời gian phản hồi từ bộ phận hỗ trợ.