Integración de sistemas municipales y APIs: cómo contratar un proyecto de interoperabilidad

La integración de sistemas municipales se ha convertido en uno de los retos principales de la transformación digital en ayuntamientos. Una entidad puede disponer de sede electrónica, gestor de expedientes, contabilidad, padrón, tributos, firma, notificaciones, archivo, recursos humanos y aplicaciones sectoriales, pero seguir trabajando con procesos manuales si esos sistemas no comparten información correctamente.

El problema suele aparecer cuando un empleado descarga un fichero de una aplicación, lo transforma en Excel y vuelve a cargarlo en otra; cuando una solicitud online termina introduciéndose manualmente en un gestor; o cuando dos plataformas mantienen versiones distintas de la misma información. En esos casos, el ayuntamiento necesita un proyecto de integración mediante APIs, servicios web, middleware o conectores.

La integración debe plantearse dentro de una estrategia de digitalización de la Administración Pública y con criterios de interoperabilidad, seguridad y mantenibilidad. Si el proyecto se contrata externamente, el pliego debe describir qué sistemas se conectan, qué datos se intercambian y cómo se verificará el resultado.

Qué significa integrar sistemas municipales

Integrar no es simplemente conseguir que dos aplicaciones envíen datos. Una integración sostenible debe definir formato, significado, reglas, autenticación, errores, trazabilidad y mantenimiento.

Por ejemplo, conectar la sede con el gestor de expedientes puede requerir trasladar datos de la persona interesada, documentos, identificadores del procedimiento y referencias de registro. Si uno de esos elementos se interpreta de forma distinta en el destino, la integración puede parecer técnicamente correcta y generar errores administrativos.

La guía sobre interoperabilidad entre Administraciones Públicas desarrolla esta diferencia entre una conexión puntual y una arquitectura realmente interoperable.

Cuándo necesita un ayuntamiento un proyecto de integración

Hay varias señales claras: duplicación de datos, tareas de copia y pega, importaciones manuales, documentos que circulan por correo interno, diferencias entre sistemas o retrasos porque una unidad espera información de otra aplicación.

También es frecuente que el problema aparezca después de implantar una nueva plataforma. La herramienta funciona bien de forma aislada, pero el flujo completo sigue dependiendo de procesos manuales.

Una auditoría tecnológica municipal permite identificar estas dependencias antes de definir un nuevo contrato.

Inventario de sistemas y responsables

El proyecto debe comenzar con un inventario de aplicaciones, bases de datos, servicios, proveedores y responsables. Cada sistema debería documentarse con su función, tecnología, interfaces disponibles, criticidad y datos que maneja.

También conviene identificar qué aplicaciones son propias, cuáles se prestan como SaaS, cuáles dependen de una diputación u otra Administración y cuáles requieren colaboración del proveedor actual para acceder a sus APIs.

Este mapa evita diseñar integraciones sobre supuestos que después no pueden ejecutarse.

APIs: qué debe revisar la Administración

Una API permite que una aplicación solicite o envíe información a otra de forma estructurada. Sin embargo, que un proveedor indique que dispone de API no significa que cualquier integración sea posible.

El ayuntamiento debería conocer endpoints disponibles, métodos, formatos, autenticación, límites de uso, versionado, documentación, entorno de pruebas y condiciones de licencia.

También debe comprobarse si la API permite únicamente consultar información o también crear y actualizar registros.

REST, SOAP y otros mecanismos

En el ecosistema público conviven tecnologías de distintas generaciones. Algunas plataformas utilizan APIs REST y JSON, mientras otras exponen servicios SOAP o intercambios mediante ficheros estructurados.

El objetivo del contrato no debería ser imponer una tecnología por moda, sino garantizar una integración estable, documentada y mantenible.

Cuando no existe API puede ser necesario analizar bases de datos, colas, exportaciones programadas o mecanismos alternativos, siempre evitando soluciones frágiles cuando exista una opción estructurada.

Middleware y capa de integración

Cuando un ayuntamiento tiene muchas aplicaciones, conectar cada sistema directamente con todos los demás puede crear una arquitectura difícil de mantener. Una capa intermedia puede centralizar transformaciones, autenticación, colas y trazabilidad.

El middleware no siempre es necesario, pero puede aportar orden cuando existen múltiples proveedores y flujos.

Una buena arquitectura debe evitar que cada cambio en una aplicación obligue a modificar numerosas conexiones independientes.

Modelo de datos común

Uno de los trabajos más importantes es acordar qué significa cada dato. Campos como tercero, unidad, expediente, procedimiento, dirección o estado pueden tener estructuras diferentes en cada sistema.

La integración debe incluir un mapeo entre origen y destino y documentar reglas de transformación. Cuando existe un identificador común, debe aprovecharse para evitar coincidencias por nombre o texto libre.

Elementos como DIR3 y SIA muestran la importancia de utilizar identificadores y catálogos coherentes.

Fuente maestra de cada dato

Cuando dos aplicaciones contienen la misma información, el proyecto debe definir cuál es la fuente de referencia. De lo contrario, cada sistema puede terminar sobrescribiendo al otro.

Por ejemplo, si el padrón mantiene una dirección y otro sistema guarda una copia, debe establecerse cuándo se sincroniza, quién puede modificarla y qué ocurre si existen diferencias.

Esta decisión es parte de la gobernanza del dato y debe resolverse antes de programar el conector.

Integración con sede electrónica

La sede es uno de los puntos donde una buena integración genera más impacto. Los datos aportados por el ciudadano deberían llegar estructurados al sistema de tramitación siempre que sea posible.

La guía sobre sede electrónica de un ayuntamiento explica por qué un trámite no está realmente digitalizado si termina en una tarea de recaptura manual.

El proyecto debe comprobar también documentos, firmas, justificantes y estados del trámite.

Gestor de expedientes como núcleo

Muchas integraciones terminan o comienzan en el gestor de expedientes. Registro, firma, notificaciones y aplicaciones sectoriales pueden necesitar leer o escribir información en él.

La guía sobre expediente electrónico municipal ayuda a identificar documentos, metadatos e índices que deben mantenerse.

Si el gestor no dispone de API suficiente, el pliego debe aclarar qué colaboración prestará su proveedor.

Integración con firma electrónica

Los flujos de aprobación pueden necesitar enviar documentos a firma y recuperar el resultado con sus evidencias. La integración debe saber qué documento se firma, qué usuario interviene y cómo se almacena la firma resultante.

La guía de firma electrónica en ayuntamientos permite revisar validación, certificados y circuitos.

Conviene evitar procesos donde el usuario tenga que descargar el documento, firmarlo fuera y volverlo a subir.

Notificaciones y comunicaciones

Un proceso puede necesitar generar una comunicación, enviarla al sistema correspondiente y actualizar el estado cuando se produce una puesta a disposición o resultado.

La integración debe registrar errores y evitar duplicar envíos si una operación se reintenta.

La guía sobre notificaciones electrónicas en ayuntamientos ayuda a contextualizar estos flujos.

Plataforma de Intermediación de Datos

Algunos procedimientos pueden consultar información de otras Administraciones mediante servicios de intermediación, siempre que exista base jurídica y servicio disponible.

La Plataforma de Intermediación de Datos puede integrarse dentro de flujos para reducir certificados y tareas manuales.

El sistema debe mantener trazabilidad de consultas y tratar correctamente errores o indisponibilidad.

FACe y sistemas económicos

Los procesos de factura electrónica pueden requerir intercambio entre FACe, registro contable y sistema económico municipal.

La guía de FACe para ayuntamientos muestra cómo los códigos DIR3 y la integración condicionan la gestión práctica.

La automatización debe evitar que la información económica se copie manualmente entre plataformas.

Autenticación entre sistemas

Las integraciones necesitan credenciales técnicas. Pueden utilizar tokens, certificados, claves o mecanismos OAuth según la arquitectura.

Las credenciales no deben quedar incrustadas en código sin protección ni asociadas a cuentas personales de empleados.

El proyecto debe definir almacenamiento seguro, rotación, caducidad y responsable de cada secreto.

ENS y seguridad

Una integración amplía los caminos por los que circula información. Por eso debe analizarse dentro del marco de seguridad de la entidad.

La guía sobre ENS para ayuntamientos ayuda a revisar control de acceso, trazabilidad, continuidad y gestión de terceros.

También debe minimizarse la información transferida y limitar permisos de cada cuenta técnica.

Logs y trazabilidad

Cuando un dato no llega al destino, el ayuntamiento necesita saber qué ocurrió. La integración debe registrar ejecuciones, identificadores, resultado y errores de forma suficiente para investigar incidencias.

Los logs no deberían contener información sensible innecesaria. Deben conservarse conforme a las necesidades del servicio y las políticas de seguridad.

Una buena trazabilidad reduce mucho el tiempo de soporte.

Reintentos y gestión de errores

Las APIs pueden estar temporalmente indisponibles. El conector debe distinguir errores recuperables de errores funcionales.

Puede utilizar reintentos, colas y alertas, pero siempre evitando duplicar operaciones. Si una solicitud ya fue creada, repetirla sin control puede generar registros duplicados.

El pliego debería exigir una estrategia de idempotencia cuando resulte necesaria.

Monitorización y cuadro de mando

Las integraciones críticas deben poder supervisarse. Un panel puede mostrar ejecuciones, errores, latencias, colas pendientes y disponibilidad de servicios.

El ayuntamiento debería tener acceso a esa información sin depender exclusivamente de avisos del proveedor.

La monitorización permite detectar degradaciones antes de que se conviertan en un bloqueo administrativo.

Entornos de pruebas

Siempre que sea posible deben existir entornos separados de producción. Las pruebas deben realizarse con datos controlados y cubrir casos normales, excepciones y errores.

Cuando una plataforma externa no dispone de sandbox, el proyecto deberá acordar mecanismos seguros de prueba.

La aceptación no debe basarse únicamente en una demostración preparada por el adjudicatario.

Pruebas extremo a extremo

Una integración puede funcionar aislada y fallar en el proceso completo. Por eso deben probarse recorridos desde el evento inicial hasta el resultado final.

Por ejemplo, una solicitud puede entrar por sede, registrarse, crear expediente, generar tarea y terminar en notificación. Cada transición debe comprobarse.

La licitación de automatización de procesos ofrece criterios útiles para diseñar estas pruebas.

Versionado de APIs

Los proveedores pueden actualizar sus interfaces. El contrato debería contemplar cómo se comunicarán cambios, qué periodo de compatibilidad existirá y quién asumirá adaptaciones.

También conviene documentar la versión utilizada por cada integración.

Sin esta información, una actualización externa puede romper un proceso sin que el ayuntamiento conozca la causa.

Documentación técnica

Cada conector debería disponer de diagrama, sistemas implicados, endpoints, autenticación, mapeo de datos, reglas, errores y procedimiento de recuperación.

La documentación debe quedar en repositorios institucionales y actualizarse con los cambios.

Esto reduce dependencia del equipo que desarrolló inicialmente la integración.

Propiedad del código y repositorios

Cuando se desarrolla middleware, conectores o scripts a medida, el pliego debe definir propiedad, acceso al código, repositorios, despliegue y documentación.

La entidad debe saber qué necesita para continuar el servicio con otro proveedor.

La reversibilidad debe considerarse desde el primer día, no al finalizar el contrato.

Cómo contratar un proyecto de integración

El objeto debe identificar sistemas, procesos y resultados esperados. Si todavía existe incertidumbre, puede estructurarse una primera fase de análisis y diseño antes del desarrollo.

La guía sobre pliego técnico de digitalización municipal ayuda a definir requisitos, entregables y criterios de aceptación.

También puede resultar útil una asistencia técnica cuando intervienen muchos proveedores.

Criterios de aceptación

La aceptación debe comprobar datos correctos, ausencia de duplicados, gestión de errores, seguridad, rendimiento y documentación.

Los casos de prueba deben relacionarse con escenarios reales y dejar evidencia verificable.

Si la integración es crítica, puede incluirse una fase de estabilización antes de la aceptación definitiva.

Soporte y mantenimiento

Las integraciones cambian porque cambian las aplicaciones. El contrato debe diferenciar incidencias, adaptaciones por versiones y nuevas funcionalidades.

También conviene fijar SLA según criticidad y horario de los procesos.

Un conector que participa en cientos de expedientes diarios necesita un soporte diferente de una integración mensual.

Qué puede aportar BlackHold Consulting

BlackHold Consulting trabaja en proyectos directamente relacionados con este tipo de necesidades: digitalización e integración de procesos, automatización de procesos, automatización de tareas administrativas y automatización de gestión documental.

También dispone de capacidades de automatización de procesos complejos, consultoría estratégica tecnológica, agentes e integraciones con IA y servicios de automatización. En una Administración Pública, cualquier prestación debe contratarse mediante el procedimiento que corresponda y conforme a criterios objetivos.

Checklist para licitar integraciones municipales

Sistemas

¿Están identificados origen, destino y responsables?

API

¿Existe documentación, autenticación y entorno de prueba?

Datos

¿Se ha definido fuente maestra y mapeo?

Errores

¿Hay reintentos, alertas y prevención de duplicados?

Seguridad

¿Las credenciales y permisos están controlados?

Pruebas

¿Se validará el proceso completo extremo a extremo?

Documentación

¿El ayuntamiento recibirá código, diagramas y procedimientos?

Mantenimiento

¿Está definido cómo se adaptará el conector a cambios futuros?

Preguntas frecuentes

Conclusión

Integrar sistemas municipales significa eliminar fronteras artificiales entre aplicaciones para que la información fluya de forma controlada y trazable. El verdadero objetivo no es conectar software, sino reducir tareas manuales y mejorar el funcionamiento del procedimiento administrativo.

Un buen proyecto debe combinar APIs, modelo de datos, seguridad, monitorización, pruebas y documentación. También debe prever cambios futuros y evitar una nueva dependencia del proveedor.

Cuando el ayuntamiento necesita conectar plataformas de distintos fabricantes, desarrollar middleware o automatizar intercambios, contar con un equipo especializado en integraciones y desarrollo a medida puede convertir una arquitectura fragmentada en un ecosistema más coherente y operativo.

Fotografía: cottonbro studio / Pexels.