Errores del navegador (SDK y widget)
Envía en lotes los errores que se producen en el navegador del usuario (SDK, widget o tu propia interfaz) para verlos en la ficha de tu aplicación.
Actualizado el . 4 min de lectura
Incluido en todos los planes. Ver precios
Con este endpoint el SDK, el widget o tu propia interfaz envían en lotes los errores que se producen en el navegador del usuario. Así puedes detectar fallos de tu integración sin esperar a que alguien los cuente, y verlos en la pestaña Errores de tu aplicación (lo explica Pestaña de errores de la aplicación).
El SDK de JavaScript y el widget los envían solos. Si construyes tu propia integración, puedes llamar a este endpoint directamente.
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
endpoint admite 30 peticiones por minuto por aplicación.
Enviar errores
/api/external/v1/tickets/client-errorsEnvía un lote de hasta 10 errores del navegador para su diagnóstico. Permiso: analytics:errors:write.
Cabeceras
- X-Api-Keystringobligatorio
- Clave de API externa (formato: utl_xxx)
- Content-Typestringobligatorio
- application/json
- x-request-idstring
- Identificador único para seguir la petición
Cuerpo de la petición
- errorsClientErrorItemDto[]obligatorio
- Lista de errores que envías (máximo 10 por petición)
Estructura de cada error (ClientErrorItemDto)
- messagestringobligatorio
- Mensaje descriptivo del error (máximo 1000 caracteres)
- stackstring
- Traza de la pila del error (máximo 10.000 caracteres)
- codestring
- Código de error interno (máximo 100 caracteres). Ejemplo: NETWORK_ERROR, PARSE_ERROR
- severitystring
- Severidad del error: critical, high, medium o low
- endpointstring
- Endpoint de la API que falló (máximo 500 caracteres)
- methodstring
- Método HTTP de la petición que falló (máximo 10 caracteres)
- requestIdstring
- Identificador de la petición que provocó el error, para cruzarlo con los registros del servidor (máximo 128 caracteres)
- componentstring
- Componente de la interfaz donde ocurrió el error (máximo 100 caracteres). Ejemplo: TicketForm, ChatWidget
- urlstring
- Página donde se produjo el error (máximo 2.000 caracteres)
- userAgentstring
- Identificación del navegador del usuario (máximo 500 caracteres)
Respuesta correcta (201 Created)
- receivednumber
- Número de errores recibidos en la petición (el tamaño de la lista enviada)
Qué pasa con cada error del lote
Tu aplicación
Llega el lote
Hasta 10 errores por petición.Si no: 400 con más de 10 errores, 429 pasadas 30 peticiones al minuto.
¿Es un fallo real?
Se mira el code de cada error.Si no: un code 4xx es un error de negocio esperado y se descarta.
Se fija la gravedad
Sin severity, o con code 408, 502, 503 o 504 (un corte pasajero), queda en low.
El código es 201, no 200: acepta cualquier 2xx. Cada error se
guarda sin hacer esperar a la respuesta, así que received confirma que
ha llegado el lote, no que cada error se haya guardado ya.
Errores
| Código HTTP | Descripción |
|---|---|
| 400 | El cuerpo no pasa la validación (más de 10 errores o campos que superan los límites). Una lista errors vacía es válida y devuelve received: 0 |
| 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 | Se han superado las 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' \
-H 'x-request-id: req-errors-001' \
-d '{
"errors": [
{
"message": "Error al cargar la lista de tickets: timeout de red",
"code": "NETWORK_TIMEOUT",
"severity": "high",
"endpoint": "/api/external/v1/tickets",
"method": "GET",
"requestId": "req-listar-tickets-042",
"component": "TicketList",
"url": "https://mi-app.com/soporte",
"userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/120.0"
},
{
"message": "Error al parsear respuesta JSON del servidor",
"stack": "SyntaxError: Unexpected token < in JSON at position 0\n at JSON.parse (<anonymous>)\n at processResponse (sdk.js:142:21)",
"code": "PARSE_ERROR",
"severity": "medium",
"endpoint": "/api/external/v1/tickets/ai-suggest",
"method": "POST",
"component": "AiSuggestForm"
}
]
}'Si usas el SDK oficial de JavaScript (@utilia-os/sdk-js), el envío es automático: solo necesitas este endpoint si construyes tu integración sin el SDK.
Buenas prácticas
Qué incluir en cada error
Cuanto más contexto, más fácil el diagnóstico:
requestId: si el error ocurrió durante una petición a la API y le diste unx-request-id, pon ese mismo valor para cruzarlo con los registros del servidor.component: el componente de la interfaz donde ocurrió. Nombres claros comoTicketForm,ChatWidgetoFileUploadayudan a localizarlo.severity: clasifícalo bien. Reservacriticalpara errores que impiden del todo usar la función.
Cómo enviarlos
Como el máximo son 10 errores por petición, guárdalos en una cola local y envíalos en lotes: en cuanto la cola llegue a 10 o, si no, cada 30 segundos.
Niveles de gravedad
| Severidad | Uso recomendado |
|---|---|
critical | La funcionalidad principal está completamente bloqueada (ejemplo: no se pueden crear tickets) |
high | Falla una función importante, pero hay alternativa (ejemplo: las sugerencias con IA no cargan, pero el formulario funciona) |
medium | Algo inesperado que no bloquea al usuario (ejemplo: una respuesta que no se pudo interpretar y se puede reintentar) |
low | Problemas menores o avisos (ejemplo: no cargó una imagen de vista previa, un campo tardó en cargar) |
Siguiente paso
Revisa los errores recibidos en la pestaña Errores de tu aplicación o consúltalos por la API con los endpoints de errores de tu aplicación.