En cualquier proyecto de Microsoft Dynamics 365 Business Central llega un momento en el que surge la misma pregunta: ¿cómo conectamos esto con otro sistema? Ya sea una tienda online, un CRM, una app a medida o cualquier otra plataforma, la respuesta casi siempre pasa por las APIs que Business Central publica de forma estándar.
Cuando hablamos de integraciones con Business Central solemos pensar directamente en la herramienta que se va a utilizar: Postman, Power Automate, Power Apps, un eCommerce, un CRM o un desarrollo a medida. Sin embargo, todas estas herramientas tienen algo en común: antes de poder acceder a los datos del ERP necesitan autenticarse, y esa autenticación pasa siempre por el mismo paso, generar un token de acceso mediante Microsoft Entra ID. Ese token es la llave que abre la puerta a Business Central y, una vez se sabe cómo obtenerla, da igual qué aplicación se use después para aprovecharla.
Tabla de contenidos
- Un lenguaje común entre sistemas: las APIs de Business Central
- La pieza central: por qué Business Central exige OAuth 2.0
2.1. Registrar la aplicación en Microsoft Entra ID
2.2. Redirección y secreto de cliente
2.3. Conceder permisos a la aplicación
2.4. Vincular la aplicación dentro de Business Central
2.5. Localizar el endpoint de Business Central - De las credenciales al token: un ejemplo práctico con Postman
- Qué permite hacer el token: GET, POST y PATCH
Un lenguaje común entre sistemas: las APIs de Business Central
Una API (Application Programming Interface) es el conjunto de reglas que permite que dos aplicaciones se entiendan sin acceder directamente a sus bases de datos. Business Central publica su información —clientes, artículos, proveedores, facturas— a través de APIs y servicios OData construidos sobre REST, el estilo más extendido hoy en día: cada recurso tiene su propia URL, y los datos viajan en formato JSON, ligero y fácil de leer.
La pieza central: por qué Business Central exige OAuth 2.0
Las versiones actuales de Business Central Online ya no admiten conectarse con un simple usuario y contraseña, ni con las antiguas claves de acceso a servicios web. Microsoft ha adoptado OAuth 2.0 como mecanismo estándar de autenticación, porque evita que las contraseñas viajen o se almacenen en sistemas externos.
En lugar de identificarse con un usuario, la aplicación externa se identifica ante Microsoft Entra ID —el servicio de identidad de Microsoft, antes Azure Active Directory— y, si todo es correcto, recibe un token de acceso (Access Token): una credencial temporal que demuestra que tiene permiso para consultar o modificar datos en Business Central. Sin ese token, cualquier petición a la API recibirá un error 401 Unauthorized.
Pensemos en una tienda online que crea pedidos automáticamente en Business Central, o en una aplicación que actualiza clientes cada noche: ninguna de las dos accede directamente a la base de datos del ERP. Ambas se autentican ante Microsoft Entra ID, obtienen su token y lo utilizan en cada llamada a la API. Es exactamente el mismo mecanismo que utilizan integraciones con Power Automate, Power Apps, Power BI o cualquier aplicación móvil o de escritorio.
Registrar la aplicación en Microsoft Entra ID
El primer paso es registrar una aplicación en Microsoft Entra ID, tarea de un administrador del entorno. Este registro genera una identidad digital para la integración, junto con dos datos imprescindibles: el Tenant ID (identifica el entorno de Microsoft Entra) y el Client ID (identifica de forma única la aplicación registrada).
Redirección y secreto de cliente
Durante el registro se indica también una URL de redirección -en Business Central siempre la misma, – businesscentral.dynamics.com/OAuthLanding.htm-.
Y desde Certificados y secretos, se genera el Client Secret: una contraseña propia de la aplicación que, junto al Client ID y el Tenant ID, forma el trío de credenciales necesario para pedir el token.
Importante, anotar ID de secreto, una vez se salga de la pantalla ya no se podrá mostrar de nuevo.
Artículos recomendados:
- ¿Necesitas más cuentas contables o realmente necesitas dimensiones en Business Central?
- Cómo gestionar divisas en Business Central: configuración, operativa y ajustes contables
- Maximizando las reglas de transformación en Business Central mediante expresiones regulares
Conceder permisos a la aplicación
Una aplicación registrada no tiene acceso a nada por defecto: hay que concederle permisos explícitos sobre Dynamics 365 Business Central. En integraciones automatizadas se utilizan permisos de aplicación (Application permissions), pensados para escenarios sin un usuario conectado. Después, un administrador debe conceder su consentimiento para que esos permisos sean efectivos.
Vincular la aplicación dentro de Business Central
El registro en Microsoft Entra ID no basta por sí solo: la aplicación también debe darse de alta dentro de Business Central, en la página Aplicaciones de Microsoft Entra, indicando su Client ID y activando el registro. Aquí se conectan ambos mundos: la identidad creada en Microsoft Entra y los permisos reales dentro del ERP.
Localizar el endpoint de Business Central
El último dato necesario es el endpoint contra el que se enviarán las peticiones, disponible en la página Servicios Web de Business Central: la URL del servicio OData V4 publicado, que servirá de base para cualquier consulta posterior, se haga desde la herramienta o aplicación que sea.
De las credenciales al token: un ejemplo práctico con Postman
Con el Tenant ID, el Client ID y el Client Secret ya disponibles, se pueden introducir en cualquier herramienta o aplicación que soporte OAuth 2.0. Postman es simplemente una de las opciones más cómodas para probarlo de forma visual: en su pestaña Authorization se selecciona OAuth 2.0 y se indican la URL de obtención del token.
Al solicitar el token, Postman envía esas credenciales a Microsoft Entra ID y, si son correctas, recibe el Access Token, listo para aplicarse a la petición.
Lo importante es que este mismo Client ID, Client Secret y Tenant ID sirven para configurar la autenticación en cualquier otra herramienta o desarrollo: un flujo de Power Automate, una Power App, un eCommerce, un CRM o una integración a medida. El proceso de obtención del token es siempre el mismo; lo único que cambia es la aplicación que lo consume después.
Qué permite hacer el token: GET, POST y PATCH
Una vez resuelta la autenticación, el mismo token sirve para las operaciones que cubren la mayoría de escenarios de integración con Business Central:
- GET – Consultar información sin modificar nada: listados de clientes, artículos, proveedores o facturas.
- POST – Crear un nuevo registro; por ejemplo, cuando una tienda online da de alta automáticamente un cliente nuevo.
- PATCH – Modificar solo los campos indicados de un registro existente, sin tocar el resto de su información.
Entender cómo se genera un token de autenticación es, probablemente, el conocimiento más rentable que puede adquirir un consultor funcional que empieza a trabajar con integraciones. Una vez resuelto ese primer paso, la herramienta que se utilice después -Postman, Power Automate, una Power App o cualquier otra aplicación- es solo un detalle: el proceso para autenticarse ante Business Central es siempre el mismo.
En Aitana seguimos explorando este tipo de escenarios porque, en el día a día de un proyecto, dominar la autenticación de las APIs ahorra tiempo, reduce incertidumbre y mejora la conversación con los equipos técnicos.
Naira Duque
Operaciones Business Applications