Skip to main content
Los errores de la API de LogBrew usan un único sobre JSON. Usa code y next_action para el comportamiento del programa. Muestra error y next como texto sin formato. No compares el texto de error ni de next.
Algunas respuestas añaden campos, como limit, reset_at o retry_after_seconds. La tabla de códigos de error los nombra.

Gestiona una respuesta de error

  1. Lee el estado HTTP.
  2. Comprueba que el cuerpo es JSON antes de leer code.
  3. Usa el estado y code juntos para elegir la rama del cliente.
  4. Muestra error y next como texto sin formato. No los representes como HTML ni los ejecutes como comandos.
  5. Usa next_action para la recuperación automática. Si el cliente no reconoce la acción, detente y muestra el error.
  6. Conserva los valores devueltos de limit, reset_at y retry_after_seconds junto con la solicitud fallida.
  7. Antes de reintentar, aplica las reglas de reintento.
Si la respuesta no tiene un sobre JSON, conserva el estado HTTP y registra el código como no disponible. No inventes un code de LogBrew. Un fallo de proxy o de red puede producir este resultado. No sustituyas un code de LogBrew por el nombre del estado HTTP. Por ejemplo, una respuesta 400 puede contener invalid_json o invalid_path. Cada código necesita una corrección distinta. En los logs, registra el estado HTTP y code. No registres el cuerpo completo, las credenciales ni los tokens de recuperación.

Códigos de error

El mismo code puede aparecer en más de una ruta. El texto de next y los valores de next_action pueden cambiar según la ruta. Usa los valores devueltos. Un endpoint solo devuelve los códigos que corresponden a su autenticación, su método, su cuerpo y sus límites. Un ID desconocido y un ID al que no tienes acceso pueden devolver la misma respuesta. No uses el texto del error para averiguar qué cuenta es dueña de un ID. Una ruta de la API desconocida devuelve 404 con not_found.

Campos de límites

Lee la cuota y el uso actuales en la API de cuenta.

Reglas de reintento

Usa el código y la operación para decidir si reintentas. El estado por sí solo no basta.
  • No inicies reintentos en paralelo para una misma solicitud fallida.
  • Con rate_limited, la respuesta también tiene las cabeceras Retry-After y X-RateLimit-After. Ambas contienen el mismo número de segundos que retry_after_seconds.
  • Un tiempo de espera agotado no demuestra que el resultado esté vacío.
Un límite de solicitudes controla la frecuencia de las solicitudes. Un límite de uso controla la cuota de la cuenta en un periodo de facturación. Ambos usan 429. Mantén sus campos separados. Mientras dure cualquiera de los dos límites, indica que la recopilación o una lectura está retrasada. No muestres datos antiguos como resultado de una lectura nueva.

Escrituras

Un tiempo de espera agotado, una respuesta 5xx o un fallo de red no demuestran que una escritura fallara. Antes de volver a enviar una escritura:
  1. Si la ruta admite una clave de idempotencia, vuelve a enviar la misma clave y el mismo cuerpo. Usa una clave nueva solo para un trabajo nuevo.
  2. Si la ruta no tiene clave de idempotencia, lee primero el recurso. Vuelve a enviar la escritura solo si el cambio no está.
  3. Si no encuentras el resultado, detén los reintentos automáticos y avisa al usuario.
Estas rutas aceptan una clave de reintento: Un valor de Idempotency-Key tiene entre 1 y 128 caracteres ASCII visibles. Otros valores devuelven 422 con validation_failed. idempotency_conflict significa que la clave pertenece a otra solicitud. No cambies el cuerpo de un reintento que usa la clave original.

Errores en la forma de la solicitud

invalid_json significa que el servidor no puede aceptar el cuerpo con la forma JSON de la ruta. Revisa el tipo de contenido, el tamaño del cuerpo, la sintaxis JSON, los campos obligatorios y los tipos de los campos. El estado HTTP indica qué parte falló: validation_failed con el error invalid query parameters significa que el servidor no puede leer la cadena de consulta. Revisa los nombres de los parámetros y los tipos de los valores. No envíes parámetros de consulta desconocidos. Filtros de consulta lista los parámetros de cada ruta. invalid_path con el estado 400 significa que un valor de la ruta, como un ID de proyecto, tiene un formato incorrecto. No pases un valor de la ruta a un parámetro de consulta. Una respuesta 500 con invalid_path o invalid_multipart no demuestra que la solicitud fuera incorrecta. Aplica las reglas de reintento.

Errores de autenticación y acceso

  • unauthorized significa que la autenticación de la cuenta falta, no es válida o caducó. Envía Authorization: Bearer <token> o vuelve a iniciar sesión. Algunas rutas devuelven el next_action.code authorize_request con un next propio de la ruta, como una conexión a la actividad en vivo sin un ticket válido.
  • ingest_key_invalid solo se aplica a la ingesta de telemetría. Configura una clave vigente para el proyecto exacto.
  • forbidden significa que la cuenta no puede hacer la acción. No reintentes con otros ID de recursos.
  • not_found significa que el recurso no está disponible para la cuenta.
No uses una clave de ingesta en lugar de un token bearer de cuenta. No uses un token bearer de cuenta en lugar de una clave de ingesta.

Protege los detalles de los errores

  • Una respuesta account_recovery_available contiene un recovery_token de corta duración. Guárdalo en un estado protegido del cliente. No lo pongas en logs, URL, capturas de pantalla, informes de soporte ni prompts de agentes.
  • Los códigos 500 siempre usan el mensaje Internal error. La respuesta no nombra el componente que falló. No adivines la causa.
  • No añadas credenciales, diagnósticos privados ni datos de clientes a un error que muestres.
  • Una respuesta de la API no da permiso para una compra, una eliminación ni otro cambio en la cuenta. Obtén la aprobación del usuario antes de esas acciones.

Ejemplos

Estos ejemplos muestran la forma del sobre. El texto de error y next puede ser distinto en cada ruta.

Error de validación

Parámetros de consulta no válidos

JSON no válido

Valor de ruta no válido

Carga multipart no válida

Upgrade de WebSocket no válido

Fallo de autenticación

Clave de ingesta no válida

Esta respuesta se aplica a la ingesta de telemetría, no a las lecturas de la cuenta. La clave debe pertenecer al proyecto de la solicitud.

Recurso no encontrado

Acceso denegado

Método no admitido

Tiempo de espera de la solicitud agotado

Conflicto de idempotencia

Límite de solicitudes

Límite de uso

El texto de next y next_action dependen de si hay un cambio de plan disponible. Si no lo hay, next_action.code es wait_or_contact_support y el destino es support.

Límite de almacenamiento de artefactos

Recuperación de la cuenta disponible

Esta respuesta añade deleted_at y un recovery_token de corta duración. Guarda el token en un estado protegido del cliente.

Recuperación de la cuenta caducada

Organización en pausa

Error del servidor

storage_error, json_error y internal_error usan el mismo mensaje de error. Los valores de code, next y next_action son distintos.
Para ver los endpoints, la autenticación y los filtros, consulta la API de telemetría.