El software de rondas rara vez es el único sistema de una operación. Convive con el ERP que factura, con la nómina que paga las horas, con el sistema de tickets de mantenimiento y, cuando el cliente es grande, con su propio centro de control.
Si esos sistemas no se hablan, alguien los conecta a mano. Y "a mano" significa una persona exportando un CSV cada lunes, con el error de transcripción incorporado.
La conversación sobre la API suele llegar tarde, después de firmar, cuando ya no hay margen. Estas son las siete preguntas que conviene hacer antes.
1. ¿Es una API pública documentada o hay que pedirla?
La primera señal es si la documentación está publicada y accesible sin firmar nada. Una API que solo se documenta bajo acuerdo comercial suele significar una de dos cosas: que se construye a medida por cliente, o que no está lista.
Pide la URL de la documentación en la primera llamada. Es una pregunta de treinta segundos que ahorra semanas.
2. ¿Webhooks o solo consulta?
Es la diferencia arquitectónica que más pesa.
Con solo consulta, tu sistema pregunta cada cierto tiempo si hay novedades. Es simple de implementar y tiene dos costos: latencia — te enteras cuando toca el siguiente sondeo — y desperdicio, porque la mayoría de las consultas no devuelven nada.
Con webhooks, la plataforma te avisa cuando ocurre el evento. Es lo que necesitas si quieres que una incidencia crítica llegue al centro de control del cliente en segundos.
La respuesta correcta es que existan los dos: webhooks para reaccionar, consulta para reconciliar y para recuperarte cuando un webhook se perdió.
3. ¿Qué eventos se emiten exactamente?
"Tenemos webhooks" no dice nada. La lista concreta sí. Como mínimo debería haber:
- Escaneo de punto de control registrado.
- Incidencia abierta, actualizada y cerrada.
- Ronda completada, y ronda no completada dentro de su ventana.
- Inicio y fin de turno.
El cuarto de esa lista es el más valioso y el que más veces falta. Un sistema que solo avisa de lo que ocurrió, y no de lo que debía ocurrir y no ocurrió, deja fuera precisamente la alerta que justifica la integración.
4. ¿Los webhooks son fiables?
Tres propiedades, y las tres se preguntan explícitamente:
Reintentos. Si tu endpoint está caído dos minutos, ¿la plataforma reintenta? ¿Con qué política y durante cuánto tiempo?
Idempotencia. Cada evento debe llevar un identificador único y estable, para que al recibirlo dos veces puedas descartar el duplicado. Sin esto, cualquier reintento genera registros dobles en tu sistema.
Firma. El payload debe venir firmado para que puedas verificar que viene de quien dice. Un endpoint público sin verificación de firma acepta lo que le manden.
Si falta cualquiera de las tres, la integración va a funcionar en la demostración y a fallar en producción.
5. ¿Cómo se autentica y cómo se rota la credencial?
Un token de larga duración que no se puede rotar sin cortar el servicio es un problema de seguridad y de operación a la vez. Lo que hay que poder hacer:
- Crear varias credenciales, una por integración, para revocar una sin afectar al resto.
- Limitar el alcance de cada credencial a lo que esa integración necesita leer o escribir.
- Rotar sin ventana de corte, es decir, con las dos credenciales válidas durante el solape.
6. ¿Qué límites de uso hay y qué pasa al alcanzarlos?
Todos los límites son razonables mientras estén documentados. Lo que no es razonable es descubrirlos en producción.
Pregunta el límite por minuto, qué código de respuesta devuelve al superarlo y si la respuesta indica cuánto esperar antes de reintentar. Y pregunta si el límite se aplica por credencial o por cuenta, porque cambia por completo cómo repartes las integraciones.
7. ¿Se puede sacar todo el histórico, no solo lo reciente?
Una API pensada solo para el tiempo real deja fuera la migración y el respaldo. Necesitas poder recorrer todo el histórico de forma paginada y reanudable, con un criterio de orden estable.
Esta es también la pregunta que responde qué pasa el día que te vayas. Una API de exportación completa es la mejor garantía de portabilidad que puede dar un proveedor, mejor que cualquier cláusula contractual.
Las tres integraciones que aportan más valor
Por si sirve de orden de prioridad, medido por lo que más veces se pide:
Incidencias hacia el sistema de tickets. Una anomalía detectada en ronda que abre automáticamente una orden de trabajo en mantenimiento. Elimina el paso manual donde se pierden los hallazgos.
Horas hacia nómina. Inicio y fin de turno reales, con la salvedad de que el registro de rondas no es un reloj checador y no debe usarse como tal sin verificarlo contra la normativa laboral aplicable.
Eventos hacia el centro de control del cliente. Es la que gana contratos. Un cliente que ve tus incidencias en su propio tablero, en su formato, deja de compararte por precio.
Cuándo no hace falta API
Conviene decirlo. Si operas dos sitios, una persona arma el reporte mensual en veinte minutos y ningún cliente pide integración, no necesitas API: necesitas una buena exportación.
Pagar por capacidad de integración que no vas a usar es el error simétrico al de no preguntar. La pregunta útil no es "¿tiene API?" sino "¿qué sistema concreto quiero conectar y qué evento necesito de él?".
Cómo lo resolvemos
Documentación pública sin registro previo, webhooks firmados con reintentos e identificador de evento estable para descartar duplicados, y consulta paginada de todo el histórico para reconciliación y para exportación completa. Los eventos incluyen la ronda no completada dentro de su ventana, no solo la completada. Las credenciales se crean por integración, con alcance limitado y rotación sin corte.
Para profundizar
- /blog/pliego-tecnico-licitacion-software-rondas-seguridad-privada — cómo se redactan estos requisitos en un pliego.
- /blog/como-elegir-software-de-rondas-2026-criterios-y-checklist — el checklist completo de evaluación.
- /blog/auditoria-bitacora-rondas-12-fallos-tipicos — qué debe conservar el registro que exportas.