Una ingeniería prescribe a su cliente una plataforma de gestión de activos en parte por una frase que aparecía en la presentación comercial: API abierta, se integra con cualquier sistema. Meses después, el cliente pide conectar la plataforma con su SAP para que los datos de mantenimiento alimenten los indicadores corporativos. La ingeniería solicita al proveedor la documentación de la API y recibe, en el mejor de los casos, un PDF con una lista de endpoints que no coincide del todo con lo que el sistema hace en producción; en el peor, un formulario de contacto y la palabra roadmap. La integración que se había dado por hecha en la prescripción se convierte en un desarrollo a medida que el proveedor presupuesta aparte, y el cliente mira a la ingeniería que recomendó la herramienta.

Esta escena se repite porque "se integra con todo" es la afirmación más fácil de incluir en una oferta y la más difícil de verificar una vez firmado el contrato. Para una ingeniería, sin embargo, la API no es una funcionalidad accesoria que se comprueba al final. Es lo que determina si podrá incorporar la plataforma a su propio flujo de trabajo —los entornos BIM, CAD y GIS que ya maneja— y conectarla con los sistemas del cliente, sea un ERP, un SAP o una capa SCADA. La diferencia entre una API real y una API prometida es la diferencia entre integrar en horas y reescribir en meses, y esa diferencia la paga siempre quien prescribió.

Tener una API no es lo mismo que tener una API documentada

Conviene precisar qué se está evaluando, porque la palabra API se usa para cosas muy distintas. Que un sistema exponga algún endpoint no significa que sea integrable con garantías. Lo que hace integrable a una plataforma es una interfaz pública, documentada bajo un estándar y versionada. El estándar de referencia es OpenAPI, mantenido por una iniciativa independiente y pensado precisamente para que humanos y máquinas entiendan las capacidades de un servicio sin acceder al código fuente ni inspeccionar el tráfico de red. Una API descrita conforme a OpenAPI 3.0, con autenticación bajo un esquema reconocido como OAuth 2.0 —definido en el RFC 6749—, es algo que se puede leer, probar e integrar de forma predecible. Una API que solo existe como descripción comercial, sin documentación pública que la respalde, es una intención, no una capacidad.

La distinción importa porque el coste de descubrirla en el momento equivocado es alto. Si la ingeniería asume que la integración existe y la promete a su cliente como parte del entregable, queda expuesta a un riesgo que no controla: que el día de conectar con el SAP el proveedor no pueda mostrar una documentación que cubra las entidades necesarias. Y las entidades necesarias en gestión de activos son concretas: activos con sus geometrías, órdenes de trabajo, lecturas de campo, eventos operativos. Una API que documenta el catálogo de productos pero no expone la geometría del activo no sirve para el caso de uso que importa.

Cómo se verifica antes de prescribir

La protección frente a esta sorpresa se construye en la fase de selección, y se construye con comprobaciones concretas que una ingeniería puede incorporar a su proceso sin coste. La primera es pedir la URL de la documentación OpenAPI y confirmar que existe, que es pública y que está versionada. Si el proveedor no puede mostrarla y remite a una llamada con su equipo técnico, eso ya es una respuesta. La segunda es revisar que la documentación cubre las entidades que el caso de uso necesita, no solo las genéricas. La tercera es ejecutar, durante el piloto, una llamada real contra un dato real y comprobar que devuelve lo que la documentación promete. La cuarta es verificar la existencia de webhooks o eventos salientes para los hechos operativos relevantes, porque una integración seria no consiste solo en consultar datos, sino en que el sistema avise cuando algo ocurre.

A esto se añade el plano geoespacial, que en activos en red distribuida no es opcional. La plataforma debería importar y exportar en formatos estándar y, cuando proceda, exponer servicios conformes a las especificaciones del Open Geospatial Consortium, de modo que la geometría y la topología se muevan entre sistemas sin pérdida. Maptainer publica su API bajo OpenAPI 3.0 con autenticación OAuth 2.0 y webhooks para eventos operativos, pero el criterio vale para evaluar cualquier plataforma que una oficina técnica plantee prescribir: lo que se pide no es una promesa de integración, es la URL donde esa integración está documentada y se puede probar.

Lo que cambia para la ingeniería

Tratar la API como criterio técnico duro, y no como una casilla de la oferta, cambia la posición de la ingeniería frente a su cliente. Una plataforma con una API documentada y estándar se incorpora al stack de la oficina técnica sin fricción y se conecta con los sistemas del cliente en horas, lo que convierte una integración en un trabajo acotado en lugar de en un proyecto paralelo de resultado incierto. El entregable deja de ser una isla y pasa a ser una pieza que encaja en el ecosistema de datos del cliente, que es exactamente lo que un cliente industrial valora cuando decide si renueva la confianza en la ingeniería.

Hay además una consecuencia de independencia que conviene no perder de vista. Una API abierta y bien documentada es también la garantía de que los datos pueden salir de la plataforma hacia donde el cliente decida, hoy o dentro de tres años. La ingeniería que prescribe sobre ese criterio no solo resuelve la integración del presente; protege a su cliente de quedar atrapado en el futuro, y protege su propia recomendación de envejecer mal. La interoperabilidad, vista así, no es una característica técnica entre otras: es una forma de gestionar el riesgo de la prescripción.

Antes de la próxima prescripción

La pregunta útil para una oficina técnica que va a recomendar una plataforma no es si el proveedor dice tener una API. Lo dirá siempre. La pregunta es concreta y se responde en un minuto: ¿cuál es la URL pública de su documentación OpenAPI, y cubre las entidades que este cliente va a necesitar integrar? Si la respuesta es una llamada comercial en lugar de un enlace, la integración prometida todavía no existe, y prescribir sobre algo que no existe es trasladar al cliente un riesgo que la ingeniería podía haber comprobado antes de firmar.