La gestión de errores de CometAPI es más sencilla cuando separas los problemas de forma de la solicitud, problemas de autenticación, errores de ruta y fallos reintentables de la plataforma. Usa la combinación de estado HTTP, error.code y error.message para decidir si debes corregir la solicitud o reintentarla.
Triaje rápido
Envoltorio de error
Muchos fallos de CometAPI usan un cuerpo de error como este:
Algunas respuestas dejan code vacío. Cuando el estado es 500, trata error.code y error.message como la señal decisiva.
400 Bad Request
Un 400 normalmente significa que el cuerpo de la solicitud falló la validación antes de que pudiera procesarse con normalidad.
Causas comunes:
- Faltan campos obligatorios como
model
- Forma de JSON no válida
- Envío de un campo con el tipo incorrecto
- Reutilización de parámetros específicos del proveedor que el endpoint seleccionado no acepta
Empieza con una solicitud mínima conocida que funcione y luego vuelve a añadir los campos opcionales uno por uno. Compara el payload con el esquema del endpoint en la referencia de la API.
Usa una solicitud mínima como esta:
Sustituye your-model-id por cualquier model ID actual de la página de modelos de CometAPI.
No asumas que toda solicitud de chat mal formada devuelve 400. La ausencia de campos obligatorios de chat como messages también puede aparecer como 500 con error.code: invalid_request.
500 Internal Server Error
La mayoría de las respuestas 500 indican un fallo de plataforma o proveedor. Para Chat Completions, algunas solicitudes mal formadas también pueden aparecer como 500 y aun así incluir error.code: invalid_request.
Un ejemplo es una solicitud que omite messages:
Si una respuesta 500 tiene error.code: invalid_request, trátala como un problema de solicitud:
- Corrige el cuerpo de la solicitud.
- Compara el payload con el esquema del endpoint.
- Reintenta solo después de corregir el payload.
Si una respuesta 500 no apunta a una solicitud no válida, conserva el request id y usa backoff.
401 Invalid Token
Un fallo de token normalmente se ve así:
Qué comprobar:
- El encabezado debe ser exactamente
Authorization: Bearer $COMETAPI_KEY.
- Asegúrate de que tu aplicación no esté cargando una clave antigua desde
.env, el historial del shell o un almacén de secretos desplegado.
- Si una clave falla y otra clave funciona en la misma solicitud, trátalo como un problema de token, no como un problema de endpoint.
403 Forbidden
403 suele ser una de estas situaciones:
- La solicitud está bloqueada por una regla del lado de la plataforma, como el filtrado WAF
- El token o la ruta no tienen permiso para usar el model solicitado o la forma de solicitud solicitada
- El model elegido rechaza uno de los parámetros avanzados que enviaste
Qué hacer primero:
- Reintenta con una solicitud de texto muy simple contra un model que sepas que funciona.
- Elimina los campos avanzados y los parámetros específicos del proveedor, y luego vuelve a agregarlos gradualmente.
- Si la respuesta incluye un request id, consérvalo antes de contactar con soporte.
Si el mensaje menciona términos internos como group o channel, trátalos como detalles de enrutamiento, no como lo primero que debes diagnosticar desde el lado del cliente. La solución práctica sigue siendo validar primero el token, el model y la forma de la solicitud.
URL base incorrecta o ruta incorrecta
En Comet, un error en la ruta puede aparecer como:
- Una redirección
- Una respuesta HTML no JSON si tu cliente sigue redirecciones
- Un error de análisis dentro de tu SDK
- Una solicitud que nunca llega limpiamente a la capa de API
Usa esta URL base exactamente:
Comprobaciones recomendadas:
- Confirma que la URL base incluya
/v1.
- Confirma que la ruta del endpoint coincida exactamente con la documentación.
- Desactiva el seguimiento automático de redirecciones mientras depuras problemas de ruta.
413 Request Entity Too Large
Si ves 413, trátalo primero como un problema de tamaño de la solicitud. Los sospechosos habituales son:
- Cargas útiles base64 grandes
- Imágenes o audio demasiado grandes incrustados en línea
- Cuerpos multipart o JSON muy grandes
Qué hacer:
- Reduce o comprime el contenido adjunto.
- Divide los trabajos grandes en solicitudes más pequeñas.
- No asumas que la longitud del texto plano es la única causa.
429 Too Many Requests
Trata 429 como reintentable:
- Usa backoff exponencial con jitter.
- Reduce la concurrencia en ráfaga.
- Mantén activado el registro de solicitudes para que puedas ver qué ruta y model se están saturando primero.
Para un patrón de reintento reutilizable, consulta el ejemplo de backoff en Chat Completions.
503, 504, and 524
Estos estados son fallos del lado del servidor o de la clase de timeout.
Orientación práctica:
503: la ruta o el servicio del proveedor no está disponible temporalmente
504 y 524: fallos de tipo timeout entre la plataforma, el edge o el servicio del proveedor
Qué hacer:
- Reintenta con backoff.
- Conserva el
request id, endpoint, model y marca de tiempo.
- Si el mismo fallo se repite en varios reintentos, contacta con soporte con ese contexto.
Captura primero estos datos:
- Método HTTP
- Ruta del endpoint
- ID del modelo
- JSON del cuerpo de la solicitud saneado (este es el elemento más útil para la mayoría de las llamadas a la API)
- Parámetros de consulta si la solicitud que falló los usó
- Cuerpo de la respuesta exacto si tu cliente lo capturó
- Estado HTTP completo
- El
error.message exacto
- Cualquier
request id
- Marca de tiempo aproximada
- Si la misma solicitud funciona con otro modelo o con otro token
Si la ruta que falló acepta cargas de archivos (edición de imágenes, carga de audio, generación de video, etc.) en lugar de un cuerpo JSON simple, envía el payload enviado equivalente:
- Nombres de los campos y valores de texto que enviaste junto con el archivo
- Nombre del archivo, tipo de archivo y tamaño aproximado del archivo
- Si el archivo se subió directamente, se referenció mediante URL o se incrustó como base64
La forma más eficaz de reproducir un error es el payload exacto de la solicitud saneado. Para la mayoría de las llamadas a la API, eso significa el JSON del cuerpo de la solicitud sin procesar. Para las rutas de carga de archivos, eso significa la lista de campos más los metadatos del archivo.
Esto acorta significativamente el tiempo de respuesta de soporte.