Telemetría ligera del widget y del SDK
El endpoint con el que el widget y sdk.ai.reportError avisan de sus propios fallos en lotes de 10, y en qué se diferencia del registro de errores.
Actualizado el . 4 min de lectura
Incluido en todos los planes. Ver precios
POST /external/v1/tickets/client-errors recibe, en lotes de hasta 10, los fallos que el widget de soporte y sdk.ai.reportError (report_error) detectan en el navegador: una lista de tickets que no carga, una nota de voz que no se transcribe. Así tu equipo ve en la pestaña Errores que la integración falla sin esperar a que alguien lo cuente.
Este endpoint no captura los errores de tu aplicación, ni siquiera con el widget instalado: el widget solo avisa de los suyos. Para los de tu aplicación, en el navegador o en tu servidor, usa install y capture del SDK (Capturar los errores de tu aplicación), que van al registro de errores completo.
Dos formas de enviar errores
POST /tickets/client-errors
Telemetría ligera
ai.reportError. Lotes de 10, sin módulo, archivo, contexto ni agrupación propia, y una respuesta con solo los recuentos. 30 peticiones por minuto.POST /errors/report y /errors/batchRecomendado
Registro de errores
install y capture.Plan y permisos
Hace falta el aplicativo Integraciones en el plan de tu organización y el permiso analytics:errors:write en la aplicación, el mismo que el registro de errores. El endpoint admite 30 peticiones por minuto por aplicación y no gasta el cupo por hora de la clave.
Enviar fallos
/api/external/v1/tickets/client-errorsEnvía un lote de hasta 10 fallos del navegador. Permiso: analytics:errors:write.
Cabeceras
- X-Api-Keystringobligatorio
- Clave de la aplicación externa (utl_...).
- Content-Typestringobligatorio
- application/json
- x-request-idstring
- Identificador para seguir la petición.
Cuerpo
{ "errors": [...] }, con hasta 10 fallos. Una lista vacía es válida y devuelve received: 0. Cada fallo:
- messagestringobligatorio
- Mensaje del fallo, hasta 1000 caracteres. Se registra con el prefijo [SDK Client].
- stackstring
- Traza de la pila, hasta 10.000 caracteres.
- codestring
- Una etiqueta propia (NETWORK_ERROR, WIDGET_LOAD) o un código HTTP, hasta 100 caracteres. Con 408, 502, 503 o 504 se registra como low; con otro 4xx no se registra.
- severitystring
- critical, high, medium o low. Sin indicarla, low.
- endpointstring
- Ruta de la API que falló, hasta 500 caracteres.
- methodstring
- Método HTTP de la petición que falló, hasta 10 caracteres.
- requestIdstring
- Identificador de la petición que falló, hasta 128 caracteres.
- componentstring
- Pieza de la interfaz donde ocurrió (TicketForm, ChatWidget), hasta 100 caracteres.
- urlstring
- Página donde ocurrió, hasta 2000 caracteres.
- userAgentstring
- Navegador que lo envía, hasta 500 caracteres.
- releasestring
- Versión de tu aplicación, hasta 100 caracteres.
- environmentstring
- Entorno (production, staging...), hasta 40 caracteres. Se guarda en minúsculas.
Todos los fallos de esta ruta se registran en el módulo sdk-client; code, component, url y userAgent se guardan en su contexto. Un campo que no está en la lista, como context, se descarta sin error.
Qué pasa con cada fallo del lote
Un fallo del lote, de la petición al grupo
Tu web
Llega el lote
Hasta 10 fallos por petición.Si no: 400 con más de 10 fallos; 429 pasadas 30 peticiones al minuto.
¿Es un fallo real?
Se mira el code de cada fallo.Si no: un code 4xx se descarta y cuenta en discarded.
Se fija la gravedad
Sin severity, o con code 408, 502, 503 o 504, queda en low.
Respuesta
201 cuando UTILIA OS ha procesado el lote entero, en orden:
{ "received": 3, "accepted": 2, "discarded": 1 }received: fallos que traía la petición.accepted: los registrados.discarded: los que no se registraron, sea por un 4xx esperado, por los límites de ritmo y de cupo del registro de errores, por saturación o por un fallo al guardar. Siemprereceived = accepted + discarded.
La respuesta no dice qué fallo concreto se descartó ni por qué. Si lo necesitas, usa el registro de errores, que responde por cada uno.
Errores
| HTTP | Cuándo |
|---|---|
400 | El cuerpo no pasa la validación: más de 10 fallos o un campo que supera su límite. |
401 | Falta la clave de API o no es válida. |
403 | El plan no incluye Integraciones (MODULE_NOT_ENABLED) o falta analytics:errors:write (INSUFFICIENT_SCOPE). |
429 | Más de 30 peticiones por minuto. |
Ejemplos
curl -X POST 'https://os.utilia.ai/api/external/v1/tickets/client-errors' \
-H 'Content-Type: application/json' \
-H 'X-Api-Key: utl_tu_clave_de_api' \
-d '{
"errors": [
{
"message": "No se pudo cargar la lista de tickets",
"code": "NETWORK_TIMEOUT",
"severity": "high",
"endpoint": "/api/external/v1/tickets",
"method": "GET",
"component": "TicketList",
"url": "https://mi-app.com/soporte",
"release": "1.1.0",
"environment": "production"
}
]
}'Qué gravedad poner
| Gravedad | Cuándo |
|---|---|
critical | La función principal está bloqueada del todo: no se pueden crear tickets. |
high | Falla una función importante, pero hay alternativa: las sugerencias con IA no cargan y el formulario funciona. |
medium | Algo inesperado que no bloquea a la persona y se puede reintentar. |
low | Problemas menores: una vista previa que no carga, un campo que tarda. |