Respuesta breve: con la arquitectura V17 de Mikro, su integración debe construirse ahora sobre la Mikro Desktop API oficial y no sobre el acceso directo por SQL. La frase que repiten los integradores del mercado, “en V17 se cerró el acceso directo a la base de datos y el sistema pasó a ser totalmente basado en API”, es un resumen contundente, pero no del todo exacto: la propia documentación oficial de Mikro indica con claridad que los campos de tabla que no aparecen en el JSON de la API aún pueden usarse directamente por sus nombres de base de datos. Por tanto, la lectura correcta es esta: con V17, la API oficial pasó a ser el canal de integración principal y con soporte; para los campos que la API no expone sigue existiendo una excepción documentada de “acceso por nombre de base de datos”. ¿Qué debe hacer ahora? Tres pasos: (1) inventariar, columna por columna, todos sus puntos actuales de lectura y escritura en SQL; (2) determinar para cada campo si existe un endpoint de la API o si hay que recurrir al nombre de base de datos; y (3) solicitar una clave de API (API Key) en el portal oficial para desarrolladores, probar el nuevo flujo en paralelo y, después, realizar el cambio definitivo (cutover). En esta guía explicamos esa migración paso a paso, sin certezas inventadas y con base en la documentación oficial de Mikro.

Como empresa de ingeniería de software B2B y de marca blanca (white-label) con sede en Sakarya, gestionamos esta migración en integraciones dependientes de Mikro en los ámbitos de comercio electrónico, software a medida y contabilidad. A continuación compartimos tanto la lógica de la decisión como la guía concreta que aplicamos sobre el terreno. Solo hemos dejado como “definitivas” las afirmaciones sobre fechas y puertos que hemos podido respaldar con una fuente oficial, y señalamos claramente los puntos que son interpretación de integradores.

¿Qué ha cambiado exactamente?

Mikro publicó un portal oficial para desarrolladores de sus productos de escritorio: apidocs.mikro.com.tr. El lema del portal es “Desarrolle, pruebe, despliegue: guía de integración de la API de Mikro” y define expresamente a su público: clientes de Mikro Software, partners de Mikro Software y desarrolladores de soluciones de terceros. Es decir, esta API no es solo para distribuidores: también es el canal oficial para los equipos propios de los clientes y para las empresas de software independientes.

La naturaleza técnica de la API también es clara: REST/JSON sobre HTTP. El portal oficial ofrece guías tituladas “Fundamentos de JSON y API REST”, “Protocolo HTTP y códigos de estado” y “Uso de endpoints”, además de colecciones oficiales de Postman descargables tanto para V17 como para V16 (“Colección de Postman actual (V17)” y “(V16)”). Estas colecciones son el punto de partida oficial de su fase de pruebas.

Un matiz fundamental: decir que “V17 eliminó todo el acceso directo a la base de datos” es incorrecto. Según las preguntas frecuentes oficiales, “los campos de tabla que no están en el JSON de la API también pueden usarse directamente por sus nombres de base de datos”. El planteamiento correcto es este: la API oficial es ahora el canal principal obligatorio y con soporte, mientras que la vía del nombre de base de datos es una excepción documentada para los campos que la API no expone.

¿Por qué el acceso directo a la base de datos pasó a segundo plano? (la lógica de la decisión)

Los blogs de integradores del mercado (p. ej., ozgurguler.net, mikrodestek.net) resumen este cambio como “a partir de Mikro V17 se cerró el acceso directo a la base de datos y el sistema pasó a un modelo totalmente basado en API”. Esto debe transmitirse no como una frase oficial de Mikro, sino como una interpretación de integradores, porque no hemos encontrado esta formulación exacta en las fuentes de Mikro y la excepción del nombre de base de datos mencionada más arriba matiza esa afirmación absoluta. Aun así, la lógica técnica de que un fabricante de ERP imponga una capa de API controlada en lugar del SQL directo es clara:

  • Estabilidad e independencia del esquema: el SQL directo se acopla estrechamente a la estructura de tablas y columnas. Cuando el fabricante cambia el esquema en una versión, sus consultas se rompen sin aviso. Una capa de API coloca un contrato entre el esquema interno y el consumidor externo; aunque cambie la estructura interna, el contrato del endpoint puede mantenerse.
  • Seguridad y superficie de permisos: entregar a su aplicación credenciales directas de la base de datos (una cadena de conexión) supone la mayor superficie de permisos posible. El acceso mediante la API delega la autenticación en el propio mecanismo de sesión y autorización de Mikro, y puede restringirse por endpoint.
  • Soporte y previsibilidad: con SQL directo, el fabricante no puede saber qué lee o escribe usted; como pueden eludirse las reglas de negocio, existe un riesgo para la integridad de los datos. Las operaciones realizadas mediante la API están definidas y versionadas, y pueden recibir soporte. De hecho, Mikro publica un registro de cambios de la API V17 con fechas: el registro más antiguo que pudimos ver es [17.03a] – 14.04.2025 y el más reciente, [17.07b] – 05.08.2026. Esto demuestra que la API se versiona y evoluciona de forma activa.

¿A quién afecta?

Esta migración afecta a toda integración que se conecte directamente a la base de datos de Mikro. Los tres grupos que encontramos con más frecuencia sobre el terreno son:

  • Integraciones de comercio electrónico: tiendas que sincronizan por SQL stock, precios, cuentas corrientes y pedidos entre un sitio web o marketplace y Mikro. Las operaciones de escritura, como el descuento de stock, la creación de facturas y notas de entrega o la transferencia de pedidos, son los riesgos más críticos en este ámbito.
  • Software a medida y proyectos internos: desarrollos internos que usan Mikro como única fuente de verdad, como el seguimiento de la producción, las aplicaciones para equipos de campo o los portales de distribuidores B2B. Para este grupo, la licencia de la clave de API se gestiona manualmente (véase más abajo).
  • Integraciones de contabilidad e informes: conciliación de cuentas corrientes, puentes con e-Fatura y e-Arşiv (sistemas turcos de factura electrónica), paneles de BI e informes y exportaciones periódicas. Aunque la mayoría son de “solo lectura”, es el grupo más arraigado en las consultas directas a tablas.

Resolver los flujos de comercio electrónico y factura electrónica del lado de Mikro con un módulo listo para usar o con una integración de API a medida es una decisión en sí misma; la tratamos en un artículo aparte: Integración de comercio electrónico, ERP y factura electrónica: ¿módulo listo para usar o API a medida?

Guía de migración: de las lecturas SQL a los endpoints de la API

Los pasos siguientes son una recomendación editorial que construimos sobre los hechos que Mikro documenta. Elementos como la ejecución en paralelo y la reversión (rollback) no son un procedimiento impuesto por Mikro, sino una buena práctica estándar de integración.

1) Inventario de campos: asigne cada columna SQL

El primer paso, y el que más se omite: extraiga todas las tablas y todas las columnas que toca su integración actual. Después, elija para cada campo uno de dos caminos:

  • Si el campo está expuesto en el JSON de la API → léalo de la respuesta del endpoint REST correspondiente.
  • Si el campo no está en el JSON de la API → como indican las preguntas frecuentes oficiales, puede referenciarse directamente por su nombre de base de datos. Es una vía de escape importante que alivia la presión de “tener que convertirlo todo a la API de una sola vez”.
  • Si no existe ni como endpoint ni como campo accesible → abra una solicitud de nueva tabla o endpoint mediante el formulario de solicitud de Program API (Mikro indica: “Para solicitudes de tablas nuevas: formulario de solicitud de API”).

Las migraciones realizadas sin este inventario estallan en producción con errores de “campo faltante”. La asignación columna por columna es el paso más tedioso, pero también el más decisivo de la migración.

2) Autenticación y solicitud

Primero, el acceso: los integradores completan el formulario de solicitud de Program API. Según la guía oficial, las claves de API se asignan automáticamente a quienes usan una solución vertical; para el software interno se emite una licencia manual. (Los pasos de “evaluación detallada con preguntas y respuestas por correo electrónico y traspaso al Departamento de Contraseñas” que describen algunos blogs de integradores no están documentados de esta forma en el material oficial; la fuente oficial solo contiene el formulario, la distinción de licencias y las direcciones de contacto.)

El modelo de autenticación no es OAuth, y conviene dejarlo claro. El modelo se basa en clave de API + sesión/login. Según la guía oficial, en cada petición se usa la siguiente información:

Campo Para qué sirve
ApiKey La clave obtenida mediante la solicitud; se envía en el cuerpo JSON. Si es incorrecta, se devuelve el error “api key no válida”.
FirmaKodu Código de empresa.
CalismaYili Ejercicio contable.
KullaniciKodu Código de usuario.
Sifre Contraseña; según la guía oficial, se calcula como Fecha + Contraseña → hash MD5.

Hay una diferencia de versión en la gestión de sesiones. Los métodos V1 abren primero una sesión con APILogin (la dirección en la página oficial de instalación: POST http://localhost:8094/Api/APIMethods/APILogin, con FirmaKodu, CalismaYili, ApiKey, KullaniciKodu, Sifre en el cuerpo). Los métodos V2/V3, en cambio, envían la información del usuario directamente en el JSON de cada endpoint y cierran la sesión automáticamente al terminar la operación. Tenga en cuenta esta distinción desde el principio al diseñar su arquitectura (sesión persistente o bajo demanda).

3) Instalación y configuración de puertos

La API se instala mediante la opción “Server” de la página de actualizaciones de versión y registra un servicio de Windows llamado Mikro Desktop API. El servicio se ejecuta con la cuenta NT SERVICE\MikroDesktopAPIContainer; los parámetros del puerto se guardan en HKLM\SYSTEM\CurrentControlSet\Services\MikroDesktopAPIContainer\Parameters. Si desea cambiar el puerto, debe detener el servicio, editarlo con regedit (base decimal) y, después, abrir el puerto en el Firewall de Windows.

Los puertos predeterminados del servicio varían según la versión: 8094 para V17 y 8084 para V16. Son valores predeterminados y pueden cambiarse desde el registro; por eso, en lugar de decir “Mikro cambió el puerto de 8084 a 8094”, es más correcto decir “el valor predeterminado de V16 es 8084 y el de V17 es 8094”. Si ha personalizado este puerto en su entorno, configure sus direcciones de llamada en consecuencia.

4) Pruebas: la colección oficial de Postman

Antes de escribir código, verifique las llamadas manualmente. Descargue el paquete oficial Postman Collection (V17) de Mikro y ejecute con sus propias credenciales los endpoints que marcó en su inventario. Compare las respuestas esperadas con su salida SQL actual; no pase a producción hasta que coincidan campo por campo. En esta etapa, el canal oficial de soporte técnico es [email protected], y para consultas sobre la clave de API o sobre partners es [email protected].

5) Ejecución en paralelo y reversión

El paso que minimiza el riesgo: ejecute el nuevo flujo basado en API junto al antiguo flujo SQL. Durante un periodo definido, haga que ambas vías produzcan los mismos datos (lecturas y escrituras) y compare los resultados automáticamente (conciliación). Si no hay divergencias, la confianza aumenta. Durante este periodo, tenga listo su plan de reversión: con un interruptor de funcionalidad (feature flag) debería poder volver al flujo antiguo con un solo clic. Este enfoque de ejecución en paralelo y reversión no es una instrucción de Mikro, sino la red de seguridad estándar de integración que recomendamos.

6) Cambio definitivo y decisión de versión

Cuando la comparación esté limpia, realice el cambio definitivo: traslade el tráfico de escritura a la API, pase la vía SQL a un modo de observación de solo lectura y, después, desactívela por completo. Fije la API a una versión conocida y vuelva a ejecutar su conjunto de pruebas de regresión en Postman con cada actualización de Mikro Desktop API: el hecho de que el registro de cambios esté activo demuestra que puede haber cambios silenciosos.

Una advertencia: la frase de que Mikro ERP exige “V17 o superior” para usar la API no la encontramos literalmente en la página de inicio ni en las guías oficiales de apidocs; aparece en la página de un integrador externo (Ovo Yazılım). No presentamos este requisito de versión como fuente oficial; le recomendamos verificarlo en su propia instalación desde el navegador.

Calendario: ¿qué fechas se manejan para V16?

Para los equipos que quieran vincular la migración a un calendario, circulan con frecuencia dos fechas. No hemos podido confirmarlas en una fuente primaria de Mikro; las páginas oficiales de anuncios estaban cerradas al acceso automatizado. Las fechas siguientes se basan en el blog de un integrador que cita el anuncio de Mikro (ozgurguler.net) y en registros de quejas de consumidores; es decir, deben verificarse en el navegador, en la página oficial de anuncios de Mikro, antes de publicar:

  • 15 de octubre de 2025, fecha límite de renovación (operaciones de renovación): según la declaración transmitida, después de esta fecha todas las renovaciones se harán únicamente sobre V17. No es el fin total del soporte, sino solo la fecha límite de las renovaciones.
  • 15 de octubre de 2026, fin total del soporte: según un anuncio que se cita con fecha del 29 de septiembre de 2025, en esta fecha finalizarán por completo para V16 las actualizaciones de versión y normativas, los nuevos desarrollos, la atención al cliente y las licencias de usuarios, módulos y soluciones verticales adicionales. Es un hito distinto que llega un año después de la fecha límite de renovación; no confunda las dos fechas.

Conclusión práctica: sea cual sea la fecha que se confirme, lo más seguro es convertir la migración de su integración a la API en un proyecto y completarla mucho antes de la fecha límite. Las migraciones que se dejan para el último día eliminan tanto el margen para las pruebas como el lujo de poder revertir.

Errores frecuentes

  • Omitir el inventario: la suposición de que “la API ya lo dará todo”. Algunos campos solo están disponibles por su nombre de base de datos; para otros hay que abrir una solicitud de nueva tabla. Inventario incompleto = sorpresas en producción.
  • Confundir la autenticación con OAuth: el modelo es clave de API + login/sesión; la contraseña es Fecha + Contraseña → hash MD5. Los clientes creados con una mentalidad de Bearer token se topan con errores de “api key no válida” y de sesión.
  • Dar por sentado el puerto: quienes vienen de V16 esperan el 8084; el valor predeterminado de V17 es 8094 y puede haberse cambiado desde el registro. En lugar de fijar un puerto en el código, manténgalo configurable.
  • No fijar la versión: la API evoluciona de forma activa. Sin fijar la versión, cada actualización conlleva el riesgo de una regresión silenciosa.
  • Confundir herramientas de terceros con las oficiales: algunas utilidades de prueba o instalación que circulan en la comunidad (p. ej., una herramienta que un bloguero llama “la aplicación de pruebas gratuita que he desarrollado”) no son productos oficiales de Mikro. El recurso oficial de pruebas es la colección de Postman que publica Mikro.
  • Hacer el cambio definitivo sin un periodo en paralelo: un cambio directo sin conciliación ni reversión solo saca a la luz las incoherencias de datos a través de las quejas de los clientes.

Cómo le ayuda Partnerfy

Como empresa de ingeniería de software con sede en Sakarya, gestionamos estas migraciones de ERP no como una “promesa”, sino como un proceso repetible: primero, un inventario por campos de sus dependencias actuales de SQL; después, la construcción de la capa de integración de API (solicitud, autenticación, asignación de endpoints); y, a continuación, las pruebas con la colección oficial de Postman, la ejecución en paralelo con conciliación y un cambio definitivo controlado. Si sus flujos de CRM/ERP conectados a Mikro están en el ámbito del comercio electrónico o del software web a medida, diseñamos y mantenemos esta capa con un único punto de responsabilidad.

Una nota honesta: ningún integrador puede garantizar que un sistema que usa la API del fabricante vaya a quedar a salvo de todos los cambios de versión futuros; por eso construimos un diseño resistente a los cambios, observable y con versión fijada. También puede analizar desde otra perspectiva si le conviene invertir en un ERP/CRM específico para su empresa: ¿Le conviene un software ERP/CRM específico para su empresa?

Conclusión

Con V17, la Mikro Desktop API oficial se convirtió en el canal principal y con soporte para las integraciones; las arquitecturas ancladas en SQL directo son ahora frágiles y carecen de soporte. Pero decir que “se cerró todo el acceso a la base de datos” sería incorrecto: para los campos que la API no expone sigue existiendo una excepción documentada del nombre de base de datos. Lo correcto es elaborar un inventario por campos, solicitar el acceso a la API oficial, probar con Postman y ejecutar en paralelo antes de un cambio definitivo controlado con la red de seguridad de la reversión. Contraste con el anuncio oficial de Mikro las fechas que circulan, el 15 de octubre de 2025 y el de 2026, y no deje la migración para la fecha límite. Si desea planificar o delegar esta migración, póngase en contacto con nosotros; identificaremos sus dependencias de SQL y le propondremos un plan para trasladarlas a una API a medida.

Fuentes

Preguntas frecuentes

¿De verdad se cerró todo el acceso directo a la base de datos en Mikro V17?

No, decir que “se cerró todo” no es exacto. La API oficial es ahora el canal principal y con soporte; sin embargo, las propias preguntas frecuentes de Mikro indican que los campos de tabla no expuestos en el JSON de la API aún pueden usarse directamente por sus nombres de base de datos. La expresión “el acceso a la base de datos se cerró por completo” no es una frase oficial de Mikro, sino una interpretación de integradores.

¿Cómo solicito el acceso a la API de Mikro y cómo se obtiene una clave de API?

La solicitud se presenta mediante el formulario de solicitud de Program API de mikro.com.tr. Según la guía oficial, las claves de API se asignan automáticamente a quienes usan una solución vertical; para el software interno se emite una licencia manual. Las solicitudes de nuevas tablas o endpoints se envían mediante el mismo formulario. Para consultas técnicas, la dirección oficial es [email protected], y para lo relativo a la clave de API, [email protected].

¿La Mikro Desktop API usa OAuth? ¿Cómo funciona la autenticación?

No, no es OAuth. El modelo se basa en clave de API + sesión/login: cada petición envía ApiKey (en el cuerpo JSON), FirmaKodu, CalismaYili, KullaniciKodu y Sifre; la contraseña se calcula como “Fecha + Contraseña → hash MD5”. Los métodos V1 usan una sesión APILogin; los métodos V2/V3 envían la información directamente en cada endpoint y cierran la sesión automáticamente al terminar la operación.

¿Qué puerto usa la API de Mikro?

El puerto predeterminado del servicio varía según la versión: 8094 para V17 y 8084 para V16. Son valores predeterminados y pueden cambiarse con regedit (deteniendo el servicio y usando la base decimal); si se cambia el puerto, hay que abrirlo en el Firewall de Windows. Por eso, mantenga el puerto configurable en su cliente en lugar de fijarlo en el código.

¿Cuándo termina el soporte de V16? ¿Hasta cuándo debo migrar?

En las fuentes de integradores circulan dos fechas: el 15 de octubre de 2025 (las operaciones de renovación pasan a hacerse solo sobre V17) y el 15 de octubre de 2026 (fin completo de las actualizaciones de versión y normativas, el soporte y las licencias de V16). No hemos podido confirmar estas fechas en una fuente primaria de Mikro; verifíquelas en mikro.com.tr/duyurular antes de publicar. En cualquier caso, lo más seguro es completar la migración mucho antes de la fecha límite.

¿Por qué se elige a la mejor empresa de software en Sakarya para la integración de la API de Mikro V17?

Partnerfy, empresa de ingeniería de software B2B y de marca blanca con sede en Adapazarı, Sakarya, y oficinas en Turquía, Alemania, Rusia e Irlanda, gestiona la migración a Mikro V17 como un proceso repetible: inventario de SQL por campos, solicitud de acceso a la API oficial y configuración de la autenticación, pruebas con Postman, ejecución en paralelo con conciliación y un cambio definitivo controlado. Sin vender estadísticas inventadas ni garantías, y construyendo una integración observable y con versión fijada, figura entre las empresas preferidas para integraciones de comercio electrónico, software a medida y contabilidad.