El panel de operador de Cabgo cubre el 80% de lo que la mayoría de operaciones necesita ver a diario. El 20% restante es siempre diferente: el mapa de cancelaciones por zona de la última hora que el coordinador de turno quiere en una pantalla secundaria, la tabla de pago proyectado por conductor que el área de administración necesita antes del cierre semanal, el indicador de cobertura por zona y hora que el dueño del negocio quiere en el teléfono sin abrir el panel completo. Ese 20% existe en todas las operaciones, siempre varía y siempre requería antes contratar a alguien que lo desarrollara. Un agente de IA conectado a la API pública de Cabgo colapsa ese tiempo de semanas a horas — no porque automatice las decisiones, sino porque convierte en código ejecutable las instrucciones que el operador da en lenguaje natural.
Este artículo es para el operador técnico o integrador que ya conoce la API de Cabgo y quiere entender cómo combinarla con un agente para construir una vista custom en una tarde de trabajo real. No asume experiencia previa en construcción de dashboards, pero sí que el lector ha trabajado con APIs REST y entiende la diferencia entre una petición autenticada y una sin autenticar. El resultado concreto al final de la tarde es una página HTML funcional, un feed JSON o una hoja de cálculo actualizable — el formato depende de a quién le sirve — que muestra los datos de la operación que el panel estándar no agrega de la misma forma.
Lo que la API expone que el panel no muestra en la misma forma
La API pública de Cabgo devuelve los mismos datos que muestra el panel, pero sin los agrupamientos, filtros y ventanas de tiempo que el panel elige por diseño. Eso tiene una implicación directa para el integrador: todos los datos están disponibles, pero la forma en que llegan es la que elige quien hace la consulta, no la que impone el producto. Una consulta al endpoint de viajes con los parámetros correctos devuelve los viajes de las últimas seis horas por zona, con conductor, con estado del viaje y con tiempo de respuesta al pasajero — el panel no tiene esa vista en ese formato. Una consulta de disponibilidad de conductores en intervalos de 15 minutos permite reconstruir la curva de cobertura del turno como una tabla que no existe en ningún reporte predefinido de la plataforma.
El panel de Cabgo está optimizado para el caso de uso más común de cada operación; la API está optimizada para el que construye. La distinción importa porque muchos operadores asumen que si el panel no muestra algo, es porque la API tampoco lo tiene. En la práctica, el panel es una capa de presentación sobre la misma API disponible públicamente: lo que muestra es un subconjunto seleccionado de lo que la API expone. El integrador que entiende esa distinción tiene acceso a más datos que los que el producto estándar presenta, y el agente es el compañero que convierte esos datos en la vista específica que la operación necesita.
El agente como par de desarrollo: qué reemplaza en el ciclo de construcción
En un proceso de desarrollo tradicional, construir un dashboard interno sobre una API externa implica cuatro bloques de trabajo secuenciales: explorar la documentación para entender qué endpoints existen y qué devuelve cada uno, escribir las peticiones y manejar la autenticación, transformar el JSON en el formato que el frontend espera, y construir la interfaz. Con un agente, esos cuatro bloques colapsan en una secuencia más corta porque el agente puede ejecutar los dos primeros de forma directa — hacer las peticiones reales a la API con los datos de la operación — y asistir en los dos siguientes con código generado a partir del output real, no de ejemplos hipotéticos.
La diferencia práctica es que el agente trabaja con los datos reales de la operación desde el primer prompt, no con mocks ni con datos de ejemplo del sandbox. Cuando el operador describe lo que quiere ver — «los diez conductores con más cancelaciones en la última semana, con el porcentaje de cancelación y el promedio de tiempo entre asignación e inicio del viaje» — el agente consulta el endpoint real, devuelve los datos reales y tiene el contexto para generar el código que los convierte en una tabla HTML. El ciclo de descripción, código y validación con datos reales toma entre 15 y 30 minutos por vista, frente a varios días en un proceso de desarrollo sin agente.
El formato primero: decidir el output antes de escribir la primera consulta
Antes de hacer la primera petición a la API conviene definir en qué formato vive el output final. La elección no es técnica — es de audiencia. Tres formatos cubren el 90% de los casos de uso custom que los operadores describen:
- **Página HTML con actualización periódica**: opción con más control sobre el diseño, adecuada para pantallas de monitoreo internas que el coordinador abre en el navegador al inicio del turno. El agente genera el HTML completo con los datos embebidos y opcionalmente un script de auto-refresh para que la página se actualice en intervalos definidos sin intervención.
- **Feed JSON estructurado**: útil cuando el output alimenta otro sistema — una herramienta de BI interna, un webhook o una pantalla de Notion con integración de base de datos. El agente genera el script que hace las peticiones a la API de Cabgo y escribe el JSON en el formato que el sistema destino espera, con las transformaciones de campo necesarias.
- **Hoja de cálculo actualizable**: la opción con menor curva de entrada para el usuario final, compatible con Google Sheets vía Apps Script o con Excel vía Power Query. El agente genera el script de importación que llama a la API con las credenciales del operador y actualiza la hoja en el horario que el equipo defina.
Las primeras 90 minutos: de las credenciales a una consulta con datos reales
El primer bloque de trabajo es validar que la autenticación funciona y que la primera consulta devuelve datos de la operación correcta. Si el integrador trabaja con el agente MCP de Cabgo activo, esa validación es inmediata: el agente hace la primera petición autenticada con el token del operador y el resultado ya corresponde al tenant correcto. Si trabaja en modo API directo sin el agente MCP, el primer paso es construir la petición con el token en el header de autorización y verificar que el response incluye datos del tenant correcto — no el default del token cuando hay más de un tenant activo en la cuenta.
Una vez que la primera petición funciona, el segundo paso es construir la consulta que extrae los datos específicos que el dashboard necesita. Este es el punto donde el agente es más útil: el integrador describe en lenguaje natural qué quiere ver — «dame los diez conductores con más cancelaciones en la última semana, con el porcentaje de cancelación y el promedio de tiempo entre asignación e inicio del viaje» — y el agente genera el endpoint correcto con los parámetros de filtro, el código para transformar el response en la estructura necesaria y detecta los casos donde el dato necesita cruzarse entre dos endpoints distintos. La ventaja de ese ciclo es que el código generado parte de datos reales, no de una respuesta hipotética de la documentación.
Las siguientes 90 minutos: del output de la API a una vista legible
El segundo bloque de trabajo es convertir el JSON de la API en algo que el usuario final puede leer sin leer JSON. Para una página HTML, el agente genera el template con los datos embebidos o con el script fetch que los carga dinámicamente. El estilo puede describirse en lenguaje natural — «tabla limpia con fondo oscuro, sin bordes, texto en blanco, filas alternadas en gris oscuro» — y el agente genera el CSS correspondiente. El resultado no va a ser un diseño de producto pulido, pero sí una vista funcional que el coordinador reconoce como datos de su operación en el orden y el formato que le sirven para tomar una decisión rápida.
En este punto conviene dedicar diez minutos a probar la vista con rangos de datos extremos antes de darla por terminada: qué pasa si un conductor tiene cero viajes en el período, si una zona no tuvo actividad, si la API devuelve un array vacío en lugar del objeto esperado. El agente puede generar los casos de prueba y el código que los maneja si el integrador los describe explícitamente — ese paso no ocurre solo. Los dashboards custom casi siempre fallan en producción por las mismas razones: campos ausentes en el response, formatos de fecha inconsistentes entre endpoints y paginación que el código de la primera tarde no maneja porque los datos del período de prueba nunca superaron el límite de la primera página.
Lo que falla en producción y cómo anticiparlo antes de que ocurra
Tres problemas aparecen con más frecuencia que cualquier otro cuando un dashboard custom llega al uso diario. El primero es la autenticación: los tokens de la API tienen vigencia limitada y el dashboard que funciona el día del lanzamiento deja de hacerlo semanas después cuando el token expira. La solución es simple — un mecanismo de renovación automática del token o una alerta que avise al equipo cuando está próximo a expirar — y el agente la genera si el integrador la pide antes de terminar la sesión de construcción. El segundo es el rate limiting: cuando el dashboard hace peticiones cada cinco minutos y el coordinador lo deja abierto en varias pantallas, el número de peticiones por hora puede superar el límite que la API permite por token. Agregar caché local al script — guardar el último response y no volver a consultar hasta que pasen N minutos — también lo genera el agente en una instrucción adicional.
El tercero son los cambios de esquema: si la plataforma actualiza el formato de un campo en la respuesta del API, el código que asume el nombre anterior deja de funcionar sin un error obvio — a veces produce silencio, a veces un undefined donde debería aparecer un número. Ese riesgo es menor en APIs con versionado explícito, pero conviene documentar dentro del propio código qué campos se usan y de qué endpoint, de modo que cuando aparezca un comportamiento inesperado el diagnóstico tome minutos en lugar de horas. El agente puede generar esa documentación inline como comentarios en el script si el integrador la pide al terminar: no añade tiempo a la tarde de construcción y reduce el costo de mantenimiento en las semanas siguientes.
Lo que me sorprendió no fue que el agente generara el código — era lo que esperaba. Lo que no esperaba era que lo depurara con los datos reales de mi operación en la misma sesión. Me señaló que el endpoint de viajes paginaba en grupos de cincuenta y que mi primera versión solo mostraba la primera página. Lo corregí en diez minutos.
Un dashboard custom sobre la API de Cabgo no requiere un sprint de desarrollo — requiere una tarde con un agente bien configurado y un formato de output definido antes de empezar. La parte que el agente no reemplaza es la más importante: decidir qué vista le falta al equipo y cuánto daño operativo produce no tenerla. Ese diagnóstico siempre viene del operador que conoce su turno, no del integrador que conoce la API. Cuando las dos piezas se juntan — el operador que sabe qué necesita ver y el integrador que sabe cómo pedírselo a la API — el agente convierte esa conversación en código ejecutable en el mismo tiempo en que antes se habría redactado el brief.
El dashboard que resulta de esa tarde no va a ser perfecto: le van a faltar casos extremos que el uso diario descubrirá, algún campo cambiará de nombre con la siguiente actualización de la API y el script necesitará un ajuste menor. Eso es normal y no cambia la ecuación de fondo. Lo que sí cambia es el punto de partida: en lugar de esperar semanas a que el equipo de desarrollo tenga disponibilidad, el operador tiene una vista funcional en producción al día siguiente. Desde ahí, cada ciclo de mejora es más rápido porque el agente puede iterar sobre código existente con los datos reales que el uso diario ha generado desde que el dashboard entró en producción.
