-
SAP limita interfaces clave y endurece su política de APIs, reforzando la dependencia de BTP y Business Data Cloud.,El modelo de licencias y consumo de APIs introduce costes difíciles de prever y genera fuerte crítica de asociaciones de usuarios.,Plataformas iPaaS como Boomi y soluciones de legado como JiVS ofrecen alternativas, aunque siguen condicionadas por las APIs de SAP.,La estrategia de Clean Core y la SAP API Policy obligan a reforzar la gobernanza, revisar contratos y proteger la soberanía de los datos.
La disrupción de las API de SAP no es un tema menor ni algo que afecte solo a los equipos técnicos: está cambiando la forma en que las empresas pueden acceder a sus propios datos, integrarse con otros sistemas y plantear proyectos de IA o analítica avanzada. Lo que antes se daba por hecho -conectar SAP con casi cualquier cosa- ahora pasa por un terreno lleno de matices legales, restricciones de uso y dependencias tecnológicas muy marcadas.
En los últimos años, SAP ha ido endureciendo su política de APIs y de acceso digital, especialmente en el contexto de S/4HANA, SAP BTP, Business Data Cloud (BDC) y las herramientas de integración en la nube. Esto ha generado una tensión evidente entre la visión de SAP -un ecosistema controlado, de núcleo limpio y gobernado- y las necesidades de los clientes, que piden apertura, transparencia y costes predecibles. Vamos a desmenuzar qué está pasando, qué riesgos conlleva y qué alternativas reales existen hoy.
Arquitectura de APIs en SAP: del ERP cerrado a la infraestructura de datos abierta
Durante mucho tiempo, muchos clientes y partners han recurrido a interfaces no documentadas y accesos directos a las tablas internas de SAP para integrar, extraer datos o extender procesos. SAP lo toleró de facto por la falta de alternativas maduras, pero con el giro hacia la nube y el modelo S/4HANA Cloud, ese «vale todo» se ha terminado.
Si la gestión de la arquitectura de APIs no encaja con el modelo estándar definido por SAP, los clientes se encuentran de repente con limitaciones muy severas. El uso de esas interfaces no oficiales, que antes se miraba de reojo pero se permitía, pasa a considerarse potencialmente incumplimiento contractual, poniendo contra las cuerdas modelos de negocio que dependían de extracciones masivas de datos o integraciones altamente personalizadas.
Organismos independientes como el Open Data Infrastructure Scorecard (ODI) llevan tiempo valorando la disposición de los grandes proveedores cloud a permitir que sus clientes accedan libremente a los datos de su propia empresa. En estas evaluaciones, SAP suele salir bastante mal parada: se señalan cada vez más barreras propietarias, bloqueos a las bases de datos subyacentes y, en especial, restricciones en las interfaces de alto rendimiento utilizadas por terceros para extraer información.
El ODI confirma este diagnóstico: SAP impide la ruta directa desde S/4 a almacenes de datos externos como Microsoft Fabric y restringe la interfaz ODP (Operational Data Provisioning), que históricamente ha sido clave para la extracción masiva eficiente. Esta decisión no es meramente técnica: fuerza en la práctica a los clientes a utilizar las costosas herramientas de integración y datos propias de SAP, chocando frontalmente con la idea de una infraestructura de datos abierta y reforzando la dependencia del proveedor.
La nueva doctrina de APIs en SAP BTP, BDC e Integration Suite
Para quienes ya trabajan con SAP, la nueva doctrina restrictiva de APIs tiene un impacto directo en el diseño de su arquitectura en la nube. La Business Technology Platform (SAP BTP), la Business Data Cloud (BDC, irónicamente rebautizada como «Business Data Complexity» por DSAG) y la SAP Integration Suite pasan a estar en el centro de la estrategia… pero también de las restricciones.
El bloqueo de la extracción masiva directa de datos hacia data lakes externos obliga a muchos proyectos a pasar necesariamente por SAP BDC o Datasphere. La sensación en buena parte de la comunidad es que SAP ha levantado una especie de «aduana cerrada» para el flujo de datos: tú puedes sacar información, sí, pero solo por los carriles habilitados y con las tarifas y límites que marca Walldorf.
Aunque SAP presenta BDC como un entorno de datos abierto, con capacidades de data sharing y copia cero a través de socios como Databricks, cuando se revisa la letra pequeña de las condiciones generales aparecen las verdaderas limitaciones. El uso de las APIs de SAP para extraer datos hacia software no SAP está explícitamente prohibido, salvo que esa función esté documentada de forma expresa en la propia API. Es decir: si no está claramente permitido, se asume que no se puede hacer.
Esto enlaza directamente con la lógica de SAP Digital Access, donde ya se cobraba por la creación indirecta de documentos desde sistemas de terceros. Con la explosión de la IA y los agentes autónomos que leen y escriben datos en masa, el riesgo de que este modelo se dispare es evidente: cada interacción automatizada puede convertirse en un potencial coste adicional.
Al diseñar soluciones en SAP BTP, los clientes se ven obligados a orquestar únicamente interfaces «aprobadas», lo que multiplica el esfuerzo de desarrollo en procesos end-to-end personalizados y recorta la agilidad del negocio. El famoso concepto de SAP Clean Core pasa de ser una buena práctica recomendable a una condición de supervivencia para no salirse del marco de licenciamiento.
Licencias, uso justo y el modelo «tóxico» de acceso a las APIs
Cuando uno se adentra en las condiciones de licencia de SAP API y SAP BDC, la sensación general es que estamos ante un modelo de negocio muy agresivo hacia la base instalada. La asociación de usuarios DSAG califica sin rodeos este enfoque como algo «altamente tóxico» para los clientes existentes, porque convierte la integración y el acceso a datos en un generador constante de sobrecostes.
La propia DSAG alerta de una clara comercialización progresiva del uso de las APIs y exige modelos de «uso justo» transparentes. De lo contrario, los presupuestos de transformación digital pueden estallar: cada llamada, cada integración adicional, cada nuevo escenario de IA puede suponer un coste incremental difícil de estimar a priori.
Las condiciones de SAP Business Data Cloud incluyen, por ejemplo, límites muy estrictos de consumo: solo 2.000 llamadas a la API OData por gigabyte de memoria de cómputo al mes. Superar este umbral abre la puerta a cargos adicionales que son complicados de prever en escenarios reales donde el volumen de peticiones fluctúa enormemente.
Para añadir más incertidumbre, SAP clasifica determinados servicios críticos de BDC Connect dentro del llamado Grupo 2 de servicios de capacidad. Bajo esta categoría, SAP se reserva el derecho de cancelar esos servicios con un preaviso de seis meses, sin obligación de proporcionar un sustituto equivalente. Para cualquier responsable de datos o CIO, esto mina la seguridad de inversión a medio y largo plazo en su arquitectura de datos.
Ante este panorama, la recomendación implícita es clara: los clientes deben evaluar alternativas independientes para la gestión de APIs y la integración de datos, en lugar de depender exclusivamente de SAP BDC o SAP Integration Suite. Los proveedores de iPaaS (Integration Platform as a Service) entran en juego como contrapeso necesario.
Alternativas iPaaS y gestión del legado: Boomi, JiVS y compañía
Dentro del ecosistema de integración, soluciones como Boomi se posicionan como vías de escape frente a la hegemonía de SAP. Boomi permite encaminar datos hacia cualquier data lake en la nube, sin depender de un único proveedor, y diseñar flujos que conectan sistemas on-premise y cloud de múltiples fabricantes.
La gran ventaja es que estas plataformas iPaaS ofrecen mayor flexibilidad y menor dependencia de desarrollos ABAP propietarios, que a la larga son caros de mantener y difíciles de migrar. Aun así, no hay que engañarse: incluso estas herramientas siguen dependiendo de las APIs que SAP decide abrir o cerrar, y de cómo define sus reglas de juego.
Para la gestión de datos históricos y sistemas legacy, soluciones como JiVS de Data Migration International se presentan como una alternativa interesante. Su objetivo es sacar el peso del histórico del núcleo S/4, preservando la soberanía y el cumplimiento legal de los datos, pero en una infraestructura fuera del entorno SAP más costoso.
El problema de fondo, sin embargo, permanece: todas estas plataformas externas siguen topándose con las mismas barreras cuando SAP limita interfaces críticas como ODP. Los proveedores alternativos se ven empujados a buscar métodos creativos pero jurídicamente seguros para suplir el bloqueo de estas rutas de extracción masiva.
En otras palabras: sí hay alternativas y sí merece la pena explorarlas, pero el verdadero cuello de botella sigue estando en quién controla las puertas de acceso, es decir, en la política de APIs del propio SAP.
Clean Core, gobernanza y el nuevo rol del CCoE
El concepto de Clean Core ha pasado de ser una recomendación de arquitectura a convertirse en una especie de «hoja de parra necesaria» para justificar el endurecimiento de las políticas de extensión e integración. Bajo esta doctrina, el núcleo de S/4 debe permanecer lo más estándar posible, y las personalizaciones se trasladan al perímetro, principalmente a SAP BTP.
Para que esto funcione en un entorno S/4 Cloud, se requiere una reorganización profunda del Customer Centre of Expertise (CCoE) en cada cliente. El CCoE deja de ser un equipo centrado en tareas operativas básicas para transformarse en una instancia de gobernanza estratégica que debe vigilar cada llamada API, cada extensión y cada flujo entre sistemas.
En este modelo, solo se aceptan las APIs de lista blanca (nivel A, «whitelisted»), accesibles a través de SAP Business Accelerator Hub y orquestadas por SAP Integration Suite, para implementar extensiones side-by-side en BTP. Cualquier modificación directa del núcleo o acceso de lectura no autorizado a las tablas internas de la base de datos (niveles C y D del Clean Core) queda terminantemente prohibido.
Estas restricciones obligan a desplegar herramientas avanzadas de monitorización como SAP Cloud ALM, con las que se pueda demostrar el cumplimiento de las normas, auditar el uso de las APIs y reaccionar si se sobrepasan cuotas o se emplean interfaces no permitidas.
Además, el equipo interno debe desarrollar competencias en modelos de programación modernos como CAP (Cloud Application Programming Model) y RAP (RESTful Application Programming Model). La lógica crítica para el negocio se debe implementar en BTP bajo estos modelos, con APIs oficiales y extensiones desacopladas, de forma que sea sostenible a futuro y compatible con la política de licencias.
DSAG y la batalla por la soberanía digital de los clientes SAP
La asociación de usuarios de SAP de habla alemana, DSAG, se ha convertido en una de las voces más críticas frente a la política actual de APIs. Sus mensajes son muy claros: los clientes no deben aceptar sin cuestionar el nuevo enfoque de SAP y tienen que exigir definiciones nítidas, documentación completa y seguridad jurídica en todo lo que afecte a la integración.
DSAG reclama a SAP que todas las APIs relevantes estén documentadas de forma exhaustiva y que esa documentación tenga carácter contractualmente vinculante. También pide periodos de transición razonables para que las arquitecturas de integración existentes -a menudo muy complejas- no colapsen de un día para otro cuando se cambian reglas o se cierran interfaces.
Además, la asociación aconseja a los clientes que ya están llevando a cabo pruebas de concepto y pilotos de IA -donde se suelen usar intensivamente APIs para leer y escribir datos- que aseguren cuanto antes su encaje legal. Cada nuevo contrato, renovación o ampliación con SAP debe examinarse con lupa para evitar restricciones técnicas posteriores o subidas de precios encubiertas mediante el control del uso de APIs.
En su llamado a la comunidad, DSAG anima a los usuarios a defender activamente su soberanía digital y a exigir transparencia total sobre uso, consumo y consecuencias comerciales de la estrategia de APIs. La preocupación de fondo es que, si SAP no corrige el rumbo, la compañía pueda verse paralizada en una fase de transformación donde la confianza del ecosistema es clave.
DSAG insiste en que las normativas sobre APIs deben ser comprensibles, fáciles de interpretar y no suponer incrementos de costes para clientes ni socios. Stefan Nogly, Director de Tecnología de DSAG, lo resume subrayando que, para garantizar operaciones seguras y estables, los usuarios necesitan visibilidad clara sobre uso, consumo y efectos de la política de APIs sobre sus negocios.
La SAP API Policy como mecanismo de control estratégico
Desde la óptica del GASD (otro grupo de usuarios de SAP), el diseño actual de la SAP API Policy plantea dudas importantes. La sensación es que el alcance de las restricciones va claramente más allá de lo que sería estrictamente necesario desde el punto de vista técnico, acercándose a una forma de control estratégico sobre la soberanía de los datos de los clientes.
Con el endurecimiento de la política en abril de 2026, SAP regula con mucho más detalle las condiciones para transferir datos a sistemas de terceros. Solo se consideran permitidas aquellas interfaces que estén explícitamente señaladas en el SAP Business Accelerator Hub o en la documentación oficial del producto. Cualquier otra vía queda en una zona gris o directamente prohibida.
El problema, tal y como denuncia DSAG, es que esta documentación no siempre tiene carácter contractualmente vinculante. Es decir, SAP podría modificarla, retirarla o reinterpretarla sin el mismo nivel de garantías que si estuviera incluida de forma clara en los contratos. Esa falta de solidez jurídica supone una amenaza directa para la seguridad de planificación tecnológica de los clientes.
Para preservar la capacidad de innovación y la seguridad a largo plazo de clientes y partners, GASD y DSAG insisten en que estos puntos abiertos deben aclararse cuanto antes en cooperación con SAP. No se trata solo de un debate técnico: está en juego cómo y hasta qué punto las empresas siguen siendo dueñas de sus datos y de su libertad de integrarse con otras tecnologías.
APIs en SAP: conceptos básicos, tipos y funcionamiento práctico
Más allá del ruido político y de licencias, conviene recordar qué son realmente las APIs en SAP y cómo encajan en los escenarios de integración actuales. Una API (Application Programming Interface) es, al final, un conjunto de definiciones y protocolos que permiten que dos aplicaciones se comuniquen sin necesidad de conocer los detalles internos de cada una.
En la práctica, la API hace de intermediaria entre el consumidor y el sistema backend: recibe una petición, la traduce al lenguaje que entiende el sistema (por ejemplo, un ERP SAP), y devuelve la respuesta en un formato estándar. Así, un portal web, una app móvil o un bot de IA pueden consumir procesos o datos de SAP sin «saber» cómo está programado por dentro.
Una forma sencilla de entenderlo es imaginar que eres un cliente que pide una pizza específica. El camarero (la API) recoge tu pedido, lo transmite a la cocina (el sistema SAP) y, una vez que está lista, te la trae de vuelta. Tú no necesitas conocer la receta ni ver cómo se prepara: solo defines qué quieres y recibes el resultado.
En el contexto SAP, las APIs son el pegamento que permite conectar S/4HANA, SAP SuccessFactors, Ariba, sistemas legacy, aplicaciones Node.js, frontends React, herramientas de IA y prácticamente cualquier otro componente de tu paisaje digital. Sin APIs bien diseñadas y bien gobernadas, toda esa integración se convierte en un infierno de desarrollos ad hoc.
Tipos de APIs en el ecosistema SAP: REST, OData, SOAP y más
En las plataformas modernas de SAP nos encontramos con varios tipos de APIs, cada uno con sus ventajas y escenarios de uso. Conocerlos ayuda a elegir la opción adecuada según las necesidades de cada integración.
Las APIs REST son las más habituales. Se basan en el protocolo HTTP, utilizan verbos como GET, POST, PUT o DELETE y devuelven normalmente datos en JSON. Su simplicidad, escalabilidad y compatibilidad con aplicaciones web y móviles las han convertido en el estándar de facto para muchos servicios.
Sobre esta base REST se construye OData (Open Data Protocol), muy extendido en SAP. OData añade estandarización y funcionalidades para el acceso dinámico a datos: permite filtrar, paginar, ordenar y navegar relaciones de forma uniforme. Para aplicaciones que gestionan grandes volúmenes de información y requieren consultas flexibles, OData es especialmente útil.
En contextos más tradicionales o con requerimientos de seguridad y transaccionalidad muy estrictos, se siguen utilizando APIs SOAP (Simple Object Access Protocol). Estas interfaces, típicamente basadas en XML, son más complejas que REST pero ofrecen mecanismos robustos de validación, contratos WSDL y políticas de seguridad avanzadas, por lo que siguen presentes en muchos módulos SAP clásicos.
Más allá de estos tres grandes grupos, en el ecosistema SAP también tiene cabida GraphQL, que permite que el consumidor defina exactamente qué datos necesita, reduciendo el tráfico innecesario, o las clásicas APIs de biblioteca, que ofrecen funciones encapsuladas dentro de SDKs o librerías específicas para reutilizar código.
En el SAP Business Accelerator Hub (antes API Business Hub) podemos encontrar REST, OData, SOAP y otros artefactos como eventos, vistas CDS o adaptadores. Todo esto permite cubrir casos de uso que van desde la exposición de datos transaccionales hasta la integración basada en eventos.
SAP API Business Hub: descubrimiento, prueba y diseño de integraciones
El SAP API Business Hub (ahora llamado SAP Business Accelerator Hub) es la puerta de entrada oficial para localizar y probar las APIs que SAP y sus socios ponen a disposición del ecosistema. Se trata de una aplicación web pública, accesible en https://api.sap.com, donde cualquier desarrollador o arquitecto puede navegar por catálogos de APIs, eventos y contenido relacionado.
En este portal se pueden explorar las APIs predefinidas para S/4HANA, SuccessFactors, Ariba, SAP Cloud ALM, BTP y otros productos. Cada API viene acompañada de documentación técnica, ejemplos de peticiones y, en muchos casos, un entorno de prueba interactivo que permite lanzar llamadas de ejemplo sin necesidad de montar nada localmente.
Para trabajar en serio con estas APIs, es habitual combinar el Business Accelerator Hub con herramientas profesionales como Swagger/OpenAPI, Postman o plugins de Eclipse o Visual Studio Code. El desarrollador puede importar las definiciones de las APIs y generar clientes, mocks, test automáticos y documentación personalizada.
Un caso típico es el uso de las APIs de SAP Cloud ALM para gestionar proyectos, tareas o incidencias. Desde Swagger o Postman se pueden parametrizar las peticiones, probar filtros y comprender la semántica de los recursos antes de integrarlos en aplicaciones propias.
Esta capacidad de descubrimiento es clave, pero como se ha comentado antes, el verdadero reto está en que las APIs publicadas en el hub estén también respaldadas por acuerdos contractuales claros y no puedan modificarse unilateralmente sin dar a los clientes margen de adaptación.
Impacto de las nuevas restricciones: IA, on-premise, OData y frontends modernos
Uno de los puntos que más dudas genera es cómo afectan las nuevas limitaciones de SAP a los agentes de IA y a las integraciones on-premise, especialmente cuando se usan frameworks como OData y RAP. Muchos equipos se preguntan si estas restricciones se aplican también cuando un frontend React o un backend Node.js consume APIs definidas en sistemas SAP locales.
La clave está en distinguir entre lo técnicamente posible y lo contractualmente permitido. Desde el punto de vista puramente técnico, si has creado una API OData en tu SAP on-premise usando RAP, un cliente React o Node.js puede seguir llamándola sin problema: HTTP sigue siendo HTTP, y los modelos de datos no se han roto por arte de magia.
Sin embargo, la nueva SAP API Policy puede introducir limitaciones sobre el «tipo» de consumidor y el uso que se hace de los datos. Si un agente de IA externo empieza a extraer grandes volúmenes de información o a generar documentos de forma masiva, es posible que esto entre en el ámbito del acceso digital indirecto y, por tanto, en modelos de licenciamiento adicionales.
En el caso concreto de las APIs on-premise basadas en OData y RAP, lo recomendable es revisar con detalle las cláusulas de licenciamiento y los documentos de uso aceptable asociados a tu versión de S/4HANA o ERP. La forma de invocar la API (React, Node.js, otra app SAP, un microservicio en BTP) puede ser irrelevante desde lo técnico, pero relevante desde lo contractual si cambia el patrón de consumo.
Por eso, muchos expertos recomiendan que, antes de escalar proyectos de IA o integraciones intensivas, se valide con SAP o con tu partner de referencia hasta dónde llega el «uso razonable» y qué escenarios podrían obligarte a adquirir licencias adicionales. No hacerlo puede implicar auditorías desagradables y facturas inesperadas.
En paralelo, no hay que olvidar la vertiente puramente funcional: las APIs siguen siendo la base para integrar SAP Fiori, SAP Cloud Platform Integration, aplicaciones móviles y cualquier desarrollo personalizado. Las restricciones actuales no significan que desaparezca la integración, sino que se exige más rigor en cómo se diseña, monitoriza y se licencia.
Con todo este contexto, la fotografía general es la de un ecosistema SAP que se apoya cada vez más en APIs para habilitar la integración, la nube y la IA, pero donde esas mismas APIs se han convertido en un instrumento clave de control comercial y técnico. Para las empresas usuarias, la única estrategia sensata pasa por entender a fondo las reglas del juego, reforzar la gobernanza interna de sus integraciones y mantener siempre abiertas vías alternativas de integración e infraestructura de datos que les permitan conservar su soberanía tecnológica a largo plazo.