MT4/MT5 Integration: A Practical Field Guide

A broker asks you to wire their CRM into MetaTrader so signups create live accounts, deposits move money on the platform, and the dashboard shows real balances and open trades. Sounds like a few API calls. Then you discover MT4 and MT5 are different products with different data models, two API surfaces each, a plugin system that runs inside the server, and a habit of dropping your connection at the worst moment. This is the field manual we wish we had on our first such integration at DayNight.

Know which API you are actually talking to

MetaTrader exposes more than one programmatic surface, and confusing them costs days. Two matter for CRM and back office work: the Manager API and the Server API (called the Gateway API on MT4).

• Manager API is what you use from outside the server, as a privileged manager login. You create accounts, read balances, list trades and positions, run balance operations (deposits, withdrawals, credit), and subscribe to real time events. This is the workhorse for nearly all CRM integrations.
• Server API / plugin model runs code inside the trade server (a DLL on MT4, a service module on MT5). You only need it to intercept events at the source, enforce custom order flow logic, or feed an external bridge with the lowest latency. It is powerful and dangerous: a bad plugin can take the server down.

Most teams should start and stay with the Manager API. Reach for plugins only when a concrete requirement (a liquidity bridge, a custom margin rule) forces it.

MT4 versus MT5: the differences that bite

Treating MT5 as "MT4 plus one" is the classic mistake. The data models are genuinely different.

Hedging versus netting

MT4 is always hedging: every order is its own position, so a client can hold long and short on the same symbol at once. MT5 supports both hedging and netting, set per account group. In netting mode a new opposing order reduces or flips the existing net position instead of opening a second one. If your CRM assumes one open position per symbol, a hedging MT5 account quietly breaks your reconciliation. Read the margin mode before interpreting positions.

Orders, deals, and positions

On MT4 the world is orders and a history that mixes open trades with balance records. On MT5 the model is cleaner but has three layers: an order is a request, a deal is an execution (a fill), and a position is the resulting net exposure. A single order can produce several deals at several prices. Reconcile against orders alone and you miss partial fills.

The biggest source of ledger drift we see is code that trusts orders and ignores deals. One order, three fills, three prices. Reconcile on deals or you will be off by real money.

Creating accounts and pulling data reliably

Account creation through the Manager API is straightforward; the bookkeeping around it is where teams slip.

• Let the platform assign the trading login, then store it on your CRM user. Never invent logins on your side.
• Map the platform group deliberately. It controls leverage, symbols, swap, and on MT5 the netting or hedging mode. A wrong group is painful to migrate later.
• Persist the mapping between CRM user, login, server, and currency in one table. Multi server brokers reuse the same login number across servers, so the server is part of the key.

Push events versus polling

There are two ways to get data out, and each fails differently, so run both.

Push via Manager API events streams trades and account changes as they happen, which keeps a dashboard live and lets you react to fills, deposits, and stop outs in near real time. The catch: events can be missed during a reconnect, and you never get an event telling you an event was lost.

Polling balances and open positions on a schedule is boring and reliable. It will never give sub second latency, but it catches everything the event stream dropped.

So use both. Events drive the live UI and immediate ledger updates; a periodic reconciliation sweep (every few minutes for balances, a fuller pass overnight) compares platform state against your CRM and fixes divergence. The platform is the source of truth; your CRM is a cache that must be corrected, never the reverse.

Keeping the ledger in sync without double counting

This part has to be exactly right because it touches money. A few rules that have saved us.

1. Idempotency everywhere. Every balance operation should carry a stable external reference. Before posting a deposit, check whether that reference already exists on the platform or in your ledger. Retries are inevitable; double credits must be impossible.
2. One writer per ledger entry. If both the event handler and the polling sweep can insert the same deal, you double count. Key ledger rows on the platform's deal or ticket id with a unique constraint.
3. Reconcile on platform identifiers, not amounts. Two deposits of the same value are not the same deposit. Match on ticket and deal ids.

Money movements run as balance operations. Keep deposits, withdrawals, and credit as distinct types: credit (bonus funds) affects margin but is not the client's withdrawable money, and mixing it into the cash balance corrupts your accounting. Record the platform ticket each operation returns. If you get no ticket back, treat the operation as unknown, not failed, and let reconciliation resolve it. Blindly retrying an "unknown" withdrawal is how you pay a client twice.

Connections, rate limits, and stability

Manager connections drop. Plan for it.

• Build reconnect with backoff, and run a reconciliation pass before trusting the event stream again.
• Respect throughput limits. Batch and pace bulk reads; hammering the manager interface gets you throttled or disconnected.
• Keep one supervised manager session rather than a connection per request. Logins are a limited, licensed resource.
• Run a heartbeat. A dead socket looks identical to a quiet market until you ping it.

Sandbox testing and the mistakes that recur

Always integrate against a demo server first, and keep a permanent staging server that mirrors production groups. Generate real fills by placing demo trades; do not assume your event handling works until you have watched a partial fill arrive as several deals.

The recurring failures are predictable. Trusting a single sync path instead of hybrid. Reconciling on orders and ignoring partial fills. Getting time zones wrong, because MetaTrader servers usually run on broker time, not UTC, and a few hours of offset scatters your daily reports. Assuming MT4 logic applies to a netting MT5 account.

None of this is exotic, but the platform punishes optimistic assumptions. Treat the trade server as the source of truth, reconcile on platform identifiers, make every money operation idempotent, and design for the connection dropping. Get those four right and the rest is ordinary engineering.