Integración terminada y límites de divulgación
EXCOIN completó un encargo de integración de MetaTrader 5 y 4 mediante API propia. Son confidenciales el cliente, alcance contratado, servidores, endpoints, licencias y datos operativos. El análisis expone problemas técnicos de este tipo de entrega; los patrones se generalizan y no revelan la infraestructura exacta. Un bróker típico busca una capa común para portal, CRM, informes y automatización sin que cada producto conozca ambas plataformas.
El objetivo no es fingir que MT4 y MT5 poseen el mismo modelo. Sus interfaces, entidades comerciales y capacidades operativas son diferentes. La API debe unificar conceptos comunes y conservar la posibilidad de expresar funciones exclusivas de cada plataforma. Las diferencias aparecen en la documentación, el contrato y las respuestas de error. Ocultarlas podría cambiar el significado de una operación comercial.
Discovery: licencias, interfaces y matriz de capacidades
MetaQuotes presenta Web API de MT5 para integrar servicios web, Manager API para administración, Gateway API para otros sistemas comerciales y otras interfaces de informes y extensiones. Para MT4 describe Manager, WebServices, Server, DataFeed y Report API; ya no vende nuevas licencias de MT4. La lista no significa que una instalación concreta ofrezca cada interfaz con todos los permisos deseados. Hay que verificar acceso, versiones, derechos de uso y restricciones contractuales.
El análisis produce una matriz por servidor real: interfaz de origen, método disponible, rol requerido, entradas y salidas, significado empresarial, límites, errores y endpoint de destino. Se distinguen consultas, escrituras y acciones administrativas privilegiadas. Una implementación completa cubre todos los elementos de esta matriz aprobada y documenta excepciones; no promete que una API pública sin restricciones exponga todo el interior de MetaTrader.
Contrato de API según los procesos del cliente
El contrato público sigue tareas del cliente y no copia mecánicamente métodos del proveedor. Separa clientes y cuentas, grupos y permisos, símbolos y datos de mercado, órdenes e historial, ejecuciones, posiciones, saldos y operaciones de cuenta, informes, administración y eventos del sistema. Cada grupo tiene inventario de lecturas, escrituras, paginación, filtros, versiones y sensibilidad de los datos. Los nombres de endpoints se fijan tras mapear las interfaces realmente disponibles.
El contrato define divisa, precisión de volumen y precio, zona horaria, identificadores de cuenta y negociación, estados y traducción de errores. La especificación OpenAPI se versiona con el código; un cambio incompatible requiere migración y convivencia temporal. Los atributos propios de una plataforma siguen explícitos como extensiones del esquema. Una respuesta no puede implicar ejecución definitiva cuando el backend solo ha aceptado una solicitud.
Adaptadores MT5 y MT4 y fuente de verdad
Cada plataforma tiene su adaptador detrás de un contrato de dominio. Este resuelve autenticación, interfaces autorizadas, conversión, límites de llamadas, reconexión y errores. La capa común no dispersa condiciones de plataforma por toda la lógica empresarial. Las pruebas del adaptador permiten que una nueva versión o servidor afecte a una frontera acotada y no obligue a reescribir portal, CRM e informes.
MetaTrader sigue siendo la fuente autoritativa del estado de trading salvo que un proceso concreto defina otra cosa. La base propia guarda correlaciones, solicitudes, proyecciones de lectura y eventos de auditoría; no es una verdad independiente sobre la ejecución final. Cada proyección incluye la hora de confirmación y versión del origen. Una discrepancia crea tarea de conciliación, no una sobrescritura silenciosa. Así, una interfaz rápida no muestra un resultado definitivo que nadie ha confirmado.
Órdenes, ejecuciones, posiciones y resultados desconocidos
Solicitud, orden, ejecución y posición son entidades distintas. Aceptar una orden no significa ejecutarla. Ejecución parcial, rechazo o cancelación requieren estados acordes con la plataforma y el tipo de cuenta. Antes de escribir, la API valida permisos, parámetros del instrumento, sesión de mercado, límites e identificador de idempotencia. La respuesta distingue aceptación para procesamiento, resultado confirmado y situación pendiente de investigación.
Tras un timeout no se envía a ciegas la misma orden. La capa conserva un identificador de correlación, consulta el origen y continúa solo según el estado real. Notificaciones duplicadas, peticiones repetidas y reinicios del worker son pruebas habituales. La conciliación compara solicitudes, eventos del servidor y estado de cuenta dentro de una ventana definida, con una excepción manual controlada. La aceptación exige seguir una orden concreta hasta su estado final.
Infraestructura global sin prometer latencia nula
El acceso mundial se diseña según regiones de usuarios, límites de datos y ubicación de los servidores comerciales. Un borde regional puede proporcionar TLS, protección de tráfico y enrutamiento; servicios de lectura y atención pueden operar en varias regiones. Las escrituras comerciales requieren un propietario claro y una ruta autoritativa al servidor MetaTrader correspondiente. No sería seguro prometer consistencia instantánea entre continentes ni asignar una cuenta a dos regiones escritoras activas sin un diseño explícito.
La topología define disponibilidad, capacidad, colas, modo degradado y redirección. Durante una interrupción la lectura puede mostrar el último estado confirmado con su hora; las escrituras se detienen si no se puede verificar la fuente de verdad. La prueba de failover incluye DNS, caché, repetición de mensajes y reconexión del adaptador. Los SLO, latencias p95/p99 y objetivos RTO/RPO solo se fijan tras medir el entorno real y licenciado del cliente.
Seguridad, identidad y separación de funciones
Identidad del cliente, cuentas de servicio y operadores privilegiados tienen límites diferentes. La API utiliza tokens breves y de alcance reducido y autorización en servidor para cada operación; separa permisos de administración, trading, informes e intervención operativa. Los secretos no entran en código ni logs; cada acceso tiene propietario y revisión. Un cambio privilegiado puede requerir segunda aprobación. Los límites de frecuencia atienden al actor y al riesgo de la acción, no solo a la dirección IP.
El modelo de amenazas incluye acceso a otra cuenta, intercambio de identificadores MT4/MT5, repetición de peticiones, abuso de rol interno, fuga de exportaciones y compromiso del adaptador. Las pruebas revisan aislamiento de clientes, permisos, tokens o firmas inválidos, rotación de claves y desconexión de interfaces del proveedor. Los controles pueden mapearse a OWASP ASVS y NIST SSDF, pero su uso no constituye certificación ni prueba de seguridad de un despliegue concreto.
Traza de auditoría y observabilidad
Un evento empresarial enlaza actor, finalidad, cuenta, representación segura de la solicitud, decisión de autorización, versiones de API y adaptador, respuesta de la plataforma y resultado final. Trazas técnicas y eventos de auditoría tienen fines y plazos de conservación diferentes. Contraseñas, tokens completos y datos personales innecesarios no deben ir a los logs. Hora coherente, claves de correlación y controles de integridad permiten reconstruir una reclamación o incidente entre servicios.
La vista operativa distingue salud de la API, conectividad MT4/MT5, profundidad de colas, actualidad de proyecciones, errores por endpoint, retraso de conciliación y estado de conmutación regional. Una alerta lleva a un responsable y a un procedimiento, no solo a un gráfico rojo. La comprobación sintética usa un escenario de prueba seguro y no una operación real. En un incidente se puede relacionar el deterioro con una versión o cambio de configuración.
Pruebas y aceptación de endpoints
Cada endpoint aprobado recibe pruebas de contrato, autorización, entrada inválida, error y tamaño o paginación. Las escrituras críticas añaden duplicados, timeout, pérdida de confirmación y cambios concurrentes. Los adaptadores se prueban primero contra simulador y después en un entorno controlado del cliente; la simulación no demuestra el comportamiento del servidor real. Los datos de prueba abarcan varias cuentas, grupos, instrumentos y modos de negociación.
La matriz de aceptación incluye ID de inventario, API y permiso de origen, resultado empresarial esperado, evidencia y propietario de la excepción. Cubre además un recorrido completo por apertura de cuenta, lectura, petición comercial, historial, informes y corrección de servicio según alcance. Una prueba de carga y recuperación incorpora degradación. Solo una matriz aceptada permite afirmar que se entregaron todos los endpoints acordados para ese proyecto.
Migración, despliegue gradual y reversión
MT4 y MT5 pueden tener historiales e identificadores distintos. Antes del cambio se mapean cuentas, grupos, instrumentos y zonas horarias, también registros sin equivalencia inequívoca. Los datos históricos se comprueban con muestras y luego con totales de conciliación. Si parte del historial queda solo en MT4, el portal debe marcarlo como fuente histórica y no presentarlo en silencio como un registro nuevo de MT5.
El despliegue comienza con consultas, sigue con escrituras seleccionadas para un grupo restringido y solo después se amplía. Las banderas de función pueden segmentar regiones, cuentas y endpoints, pero no reemplazan la autorización. Cada fase tiene plan de reversión: detener el flujo nuevo, conservar pruebas, confirmar estado en plataforma y resolver operaciones en curso. Revertir código no deshace una operación comercial ya ejecutada; eso necesita un procedimiento empresarial aprobado.
Soporte y ampliaciones después del lanzamiento
Tras la entrega, el bróker necesita responsables claros para incidentes, cambios de API del proveedor, actualizaciones de seguridad y capacidad. El modelo de servicio define contactos, gravedad, respuesta, ventanas de cambio, copias, recuperación y revisión periódica de accesos. SLO y posibles SLA se acuerdan según operación observada y límites de plataforma. Los informes no deben confundir disponibilidad de la API propia con la del servidor MetaTrader externo.
Un módulo nuevo pasa por la misma matriz: finalidad, fuente de verdad, contrato de datos, permisos, escenarios de seguridad, supervisión y aceptación. Puede ser portal de cliente, flujo CRM, informes, alertas de riesgo u otra integración si está aprobada y disponible bajo licencia. Las versiones de API protegen consumidores existentes y los endpoints antiguos tienen fecha de retirada. El valor duradero reside en cambiar una pieza sin perder control sobre el estado comercial.
Mapa de dominios y responsabilidades
El modelo de dominio precede al primer endpoint. Persona, cuenta del bróker, cuenta de trading en un servidor MT, grupo, instrumento, orden, ejecución, posición y movimiento contable son entidades distintas. Cada una necesita identificador, fuente de verdad, conservación y permisos. Vincular CRM y cuenta MT es un proceso privilegiado y versionado; corregir en silencio una relación equivocada puede abrir acceso a fondos ajenos.
La API externa traduce una tarea de negocio en llamadas seguras al proveedor. El límite decide también si una caída CRM puede frenar trading, si informes admiten proyecciones antiguas y quién aprueba cambios. Cada operación tiene iniciador, sistema confirmador, dueño de excepciones y prueba final. Estas asignaciones se documentan en vez de quedar como conocimiento informal.
Identidad de cuentas entre MT4 y MT5
El mismo número puede existir en varios servidores y pertenecer a clientes distintos. Una identidad global incluye plataforma, servidor e ID local; los sistemas externos usan una referencia estable que no se remapea en silencio. Cambio de propietario, fusión de clientes o migración requieren historial y aprobación para saber quién tuvo acceso en cada momento.
La API no puede aceptar account=12345 y elegir la primera coincidencia. La autorización compara actor, cuenta canónica y operación. Un error puede exponer historial o permitir operar en cuenta ajena. Datos de prueba reutilizan intencionadamente números en varios servidores y exigen plataforma y tenant en cada decisión.
Símbolos, instrumentos y precisión
EURUSD puede tener sufijo, horario, paso de volumen, tamaño de contrato y precisión diferentes en dos servidores. El catálogo no iguala instrumentos por nombre. Conserva identificador del proveedor, servidor, clase de activo, reglas comerciales y fechas de vigencia. Si cambia la especificación, cambia la validación previa; un formulario antiguo no basta para una orden nueva.
Precio y volumen se convierten con decimales precisos y reglas explícitas de redondeo. El float puede crear un valor rechazado o desplazar un límite. Una cotización retrasada se identifica como tal; último precio no promete ejecución. Se prueban volumen cero y máximo, cambios de sesión y un instrumento suspendido mientras el formulario sigue abierto.
Controles antes de operar y respuesta de API
Antes de enviar una orden se comprueban identidad, rol, cuenta, estado del instrumento, tipo, volumen, precio y restricciones del servidor. Las validaciones locales ayudan, pero la plataforma toma la decisión final con el estado actual. La API diferencia error de entrada, rechazo del proveedor, aceptación de proceso y resultado definitivo conocido.
Los canales pueden compartir semántica entre MT4 y MT5 sin fingir campos idénticos. Motivos propios de la plataforma se traducen a categorías públicas estables y se conservan en diagnóstico restringido. Un nuevo código no debe convertirse en unknown sin revisión. Las pruebas protegen significados, no solo códigos HTTP.
Reintentos y falsa promesa de exactamente una vez
Tras perder una respuesta de red nadie sabe si se creó la operación. La promesa exactly once se transforma en un invariante: una intención económica no debe generar dos acciones. La API conserva clave de idempotencia y hash de parámetros. Misma clave y datos devuelven el estado conocido; otra cantidad o cuenta se rechaza. El registro sobrevive reinicios y cambios regionales.
No se repite una escritura tras timeout sin comprobar primero el servidor. El resultado puede estar pendiente, ejecutado, rechazado o realmente desconocido. Lo desconocido inicia conciliación y muestra fecha de última comprobación. El operador no debe tener un botón de reintento sin explicación que pueda generar otra acción económica.
Eventos, historial y ejecución parcial
El historial no es solo una lista de órdenes. La API enlaza petición, orden del servidor, ejecución, parcial, cierre y posición para explicar varios eventos de una intención. Ejecución parcial, cancelación del resto y cambio de posición tienen hora y origen. MT4 y MT5 se mapean según su semántica real.
La sincronización gestiona huecos. El adaptador guarda checkpoints, verifica continuidad y completa intervalos tras reconexión. Los duplicados no alteran dos veces la proyección. Si no hay stream completo, se comparan snapshots periódicos. Cada proyección declara origen y momento de última confirmación.
Saldo, margen y movimientos de cuenta
Balance, equity, margen libre y créditos tienen definiciones, moneda, fuente y fecha diferentes. La vista al cliente puede ser informativa; las decisiones de trading usan el estado autoritativo. Depósitos, retiradas y correcciones manuales requieren autorización escalonada, referencia financiera y vínculo de auditoría con aprobadores.
Una diferencia entre finanzas y MT no se arregla con un asiento silencioso. Puede ser retraso, mensaje duplicado, acción manual, conversión o bug. Cada corrección exige prueba, aprobación y reversión. Se vigilan excepciones antiguas y una frecuencia anómala de ajustes, posibles señales de defecto o abuso.
Backoffice, permisos y doble control
La API administrativa puede cambiar grupos, apalancamiento, acceso y modos con impacto financiero. No es CRUD ordinario. Cada cambio registra motivo, valor anterior y nuevo, aprobador y plan de recuperación. Algunas acciones separan autor y verificador. Los permisos se limitan por servidor, grupo y operación; administradores globales son excepción vigilada.
Las cuentas de servicio tienen solo derechos necesarios del proveedor. La rotación se prueba con configuración antigua y nueva, reinicio y reversión. La revisión periódica descubre accesos sobrantes tras cambios de personal. El evento de auditoría registra quién actuó, decisión de autorización y versión de política aplicada.
Informes y consistencia histórica
Extracto de cliente, informe de riesgo y exportación regulatoria pueden usar los mismos datos para preguntas distintas. Cada uno define si representa un instante, snapshot o jornada cerrada. Zona horaria y eventos tardíos pueden recalcular resultados. La exportación lleva alcance, fecha, versión de transformación y origen.
Historias grandes se paginan y generan asíncronamente para no mantener una petición HTTP sin límite contra el servidor de trading. El acceso al archivo caduca y verifica tenant y rol. El fichero se elimina según conservación. Las pruebas evitan mezclar registros MT4 y MT5 sin indicar procedencia.
Acceso regional y ubicación de escrituras
Disponibilidad global no significa escribir activamente en varias regiones sobre una cuenta. Cada cuenta tiene ruta autoritativa y política de caída. Contenido estático, login y algunas lecturas pueden acercarse al usuario; las escrituras conservan orden e idempotencia. Redirigir tráfico no puede crear dos colas que envían la misma orden.
Cada región se mide frente al servidor MT real: latencia, disponibilidad del adaptador, antigüedad de proyecciones y recuperación. En modo degradado se puede mostrar último estado confirmado con fecha; las escrituras paran si la fuente de verdad no puede verificarse. El failover prueba operaciones incompletas, no solo healthchecks verdes.
Observabilidad, alertas y procedimientos
Una cifra de uptime no descubre un incidente de trading. El panel separa lecturas correctas, escrituras rechazadas, resultados desconocidos, lag de proyecciones, colas, reconexiones y conciliaciones abiertas. Alertas se vinculan al impacto y a un responsable. Mantenimiento planificado del proveedor no equivale a caída inesperada.
El procedimiento describe primera comprobación, acción segura, límite de automatización y contacto. Reiniciar un worker no debe borrar pruebas de una escritura incierta. La línea temporal enlaza release, configuración, alerta y evento comercial. Tras recuperar el servicio se concilia y se registra la decisión sobre cada excepción.
Carga, cuotas y protección del servidor proveedor
La API pública puede atender muchos clientes mientras la interfaz del proveedor tiene límites. El adaptador aplica cuotas por operación, servidor y prioridad. Una escritura crítica no debe quedar detrás de informes masivos, pero abrir conexiones ilimitadas tampoco es seguro. Con sobrecarga se rechaza o encola según contrato, mostrando la consecuencia. La capacidad se basa en mediciones reales.
Pruebas de carga combinan lectura histórica, recuperación tras caída, apertura del mercado y escrituras simultáneas. Miden cola de latencia, errores y vuelta a la normalidad, no solo promedios. Los límites se versionan con el servidor porque las actualizaciones cambian comportamiento. Las pruebas nunca deben generar operaciones reales involuntarias.
Versiones de contrato y cambios de plataforma
Un cambio del proveedor no necesita cambiar la API pública si el adaptador conserva significado. Si cambia un campo o error, hace falta versión de contrato. La migración explica esquemas, semántica, convivencia y retirada. Una incompatibilidad no se oculta como campo opcional que clientes antiguos ignoran.
Los tests de contrato corren contra versión conocida de adaptador y entorno autorizado cuando existe. Tras actualizar MT se verifican escrituras, historial, administración y reconexión, no solo HTTP 200. La salida a producción revisa auditoría y plan de reversión. Cambiar la fuente de verdad exige decisión arquitectónica explícita.
Seguridad más allá de una prueba rutinaria
Los escenarios graves combinan componentes legítimos: petición firmada para cuenta ajena, exportación tras cambiar rol, administración en grupo incorrecto o replay tras failover. No basta con probar inyección y login. La matriz de permisos cubre cada endpoint y adaptador, incluidos servidores históricos e informes de solo lectura.
La revisión sigue el flujo: origen de identidad, punto de autorización, contenido de logs y rotación de secretos. Una cuenta comprometida se limita, evalúa y recupera sin reescribir historial. Los registros necesitan protección contra alteración y conservación según obligaciones reales del bróker.
Entrega, soporte y ensayo de recuperación
La entrega incluye OpenAPI, matriz de capacidades, servidores y roles, procedimientos, cambios, pruebas y responsables. Un nuevo equipo debe explicar qué ocurre si se pierde la confirmación de una orden y dónde consultar estado real. De otro modo el soporte se convierte en intervenciones manuales que erosionan confianza.
Un ensayo restaura proyecciones, secretos y conexiones en un entorno aislado. Comprueba correlación de auditoría y que antiguos trabajos de escritura no vuelvan a ejecutarse. El resultado es un acta con tiempos y defectos, no solo existencia de copias. Cada módulo nuevo hereda identidad, idempotencia y observabilidad.
Resultado del estudio y siguiente paso
El propietario confirma que el encargo anónimo terminó; aquí no publicamos sus métricas. Para un nuevo cliente se solicitarían servidores y API autorizadas, roles, operaciones, regiones, conservación y escenarios de prueba. El análisis conjunto cerraría endpoints, diferencias, hitos y pruebas. Un piloto temprano debería ejercer la escritura más arriesgada y una excepción importante.
Para otro cliente, la entrega puede dividirse en lecturas, escrituras, backoffice, informes, resistencia regional y soporte. El alcance depende de licencias, seguridad y datos de operación. Los especialistas del cliente evalúan obligaciones financieras y de datos personales. Por confidencialidad EXCOIN no identifica al cliente, no publica resultados medidos ni garantiza el mismo resultado en otra infraestructura.
Referencias técnicas generales
Estos enlaces explican principios generales. No documentan la implantación confidencial del cliente.