MetaTrader APIs for Algo Trading: MQL, the Python Package, ZeroMQ Bridges and Protocol Libraries Comparederic

If you want to run a trading bot on MetaTrader but write it in Python, C# or anything other than MQL, you have four realistic options:

My short answer: for MT5, start with the official Python package. It's the one I run today. Use a bridge EA if you're stuck on MT4 or need another language. Only use a protocol library if running without a terminal is worth an unsupported dependency that can break under you. I used one in 2023, and a lot of my commits on it were about reconnecting.

The rest of this post goes through each option, with what I ran into.

Why stay on MetaTrader at all?

cTrader has official automation APIs and an open FIX API at several brokers, so it's the easier platform to build on. The reason to put up with MetaTrader is what you can trade.

The screenshot at the top is from my MT5 terminal in June 2024. The Market Watch shows 2,104 symbols available on that account, including ASX share CFDs such as A2M.ASX and an ASX200 index CFD, next to the usual forex pairs and BTCUSD. When I counted symbols over cTrader's FIX API in May 2024, the brokers I checked offered between 77 and about 2,100 symbols there. Only three of the five had any stock CFDs, and none of them listed ASX shares. I listed the numbers in Trading with cTrader as your trading platform.

So if your strategy needs share CFDs (ASX ones in particular), MetaTrader is often the only platform your broker offers them on.

An earlier version of this post said some ASX stocks "can only be traded on MetaTrader". That was too broad. Real ASX shares are traded through a stockbroker, not MetaTrader. What's MetaTrader-only at many retail brokers is ASX share CFDs.

1. Pure MQL Expert Advisor

Write the whole strategy in MQL4 or MQL5 and run it as an Expert Advisor (EA) on a chart.

Good:

• No moving parts outside the terminal. OnTick() fires on every new price, so there's no polling.
• The built-in Strategy Tester can backtest it.
• Fully supported, and it works on VPS products built for MetaTrader.

Bad:

• You're locked into MQL. Your indicator code, data pipeline and analysis libraries in other languages can't be reused.
• MQL4 and MQL5 aren't the same language, so moving from MT4 to MT5 is close to a rewrite.
• Trading across several brokers means running and coordinating a separate EA in each terminal.

If your strategy fits in one EA, this is still the simplest answer. Everything below is about the case where it doesn't.

2. The official MetaTrader5 Python package

MetaQuotes publishes a MetaTrader5 package on PyPI. Your Python program attaches to an MT5 terminal running on the same machine and can read prices, history, positions and account info, and send orders. You write no MQL at all.

This is what my current gateway uses. It's a Python process per broker that publishes prices and takes order commands over a message queue (TYO-MQ). I've had it running against Pepperstone, Eightcap, BlackBull and GO Markets demo and live accounts. The code and the problems I hit are in Building a MetaTrader 5 trading gateway in Python.

Good:

• Supported by MetaQuotes, so terminal updates don't break it.
• No MQL, no DLLs, no bridge to maintain.
• History is easy to pull (copy_rates_range, copy_ticks_range).

Bad:

• MT5 only. There's no official Python package for MT4.
• Windows only, and it needs the terminal installed and running. People run it under Wine, but that's unsupported.
• No tick events. You poll for new ticks. That's fine for bar-based strategies, not for anything latency-sensitive.
• One terminal per account. Several accounts at the same broker means several terminal installs (portable mode helps).
• Broker differences still leak through: symbol names and accepted order filling modes vary, so read them from symbol_info() rather than hard-coding them.

3. An MQL bridge EA plus messaging (ZeroMQ, sockets, files)

A small EA runs in the terminal and does nothing but relay: it sends prices and account events out, and executes order instructions that come back in. Your real strategy runs in another process, in any language.

Common transports:

• ZeroMQ. The best-known option. MQL has no ZeroMQ support of its own, so the EA calls the libzmq DLL through an MQL binding. You have to enable Allow DLL imports for the EA, and some VPS setups don't allow DLLs.
• Native MQL5 sockets (SocketCreate, SocketConnect, SocketSend). No DLL needed, but it's TCP client only (the EA connects out to your server, it can't listen). The server address must be added to the allowed list in the terminal's Expert Advisors options, and sockets can't be used from indicators.
• WebRequest to an HTTP API. Simple, but request/response only and the URL also has to be allow-listed.
• Files in the terminal's shared Common\Files folder. Crude, but it works on any build and has no network setup.

Good:

• Works with MT4 as well as MT5. For MT4 this is the only supported way to get your own code in.
• Push-style: the EA can forward every tick from OnTick() instead of you polling.
• Your strategy can be in any language and run on any OS. Only the terminal needs Windows.

Bad:

• You now maintain two programs and a protocol between them: message formats, reconnection, what happens to orders in flight if either side restarts.
• Still needs the terminal running, logged in, with AutoTrading enabled and the EA attached.
• DLL-based bridges add a native dependency that has to match the terminal's 32/64-bit build.

I haven't run a ZeroMQ bridge in production myself. My messaging layer sits behind the Python package instead (option 2), which removed the need for an EA. The trade-offs above are the ones the design forces on you, not ones I measured.

4. Third-party protocol libraries (no terminal)

Some commercial and open-source libraries reimplement the network protocol the terminal uses to talk to the broker's trade server. Your program logs in to the broker directly, with no MetaTrader installed.

I used one of these in 2023: a commercial .NET library, in a C# data collector that streamed quotes and placed orders for MT5 accounts at GO Markets and IC Markets. From that code and its commit history:

• It really is headless. The collector connects straight to the broker's trade server by IP and port. It gets quotes as push events, receives order updates, downloads month-by-month bar history and reads the full symbol spec (contract size, tick size, tick value, digits, margin currency).
• Reconnection was the hard part. My commits from July 2023 include "no quote after get reconnect from the server", "when disconnected from server and getting reconnected, the callback methods get called twice" and "a fix attempt for not being able to reconnect the server after getting disconnected". I ended up writing my own failover across a list of the broker's server addresses, re-attaching event handlers by hand after each reconnect.
• Some behaviour only worked on the first connection. There's a comment in my code that the symbol-list update event only fired on the first connect.
• I had to update the library itself ("mt5 api version update", 30 July 2023) to keep it working.

That collector stopped being developed at the end of 2023. My MetaTrader gateway since early 2024 has been the Python one in option 2, and it's what I still maintain.

Good:

• No terminal. It runs headless as a service, on Linux or anywhere .NET, Python or your language of choice runs.
• One process can hold many accounts.
• Push quotes and order updates, unlike the Python package.

Bad:

• Not supported by MetaQuotes, and reverse engineering the protocol is against MetaTrader's licence terms.
• It can break without notice. When MetaQuotes changes the protocol or a broker raises the minimum client build, you wait for the library author to catch up.
• You hand your account password to someone else's binary. With a closed-source library, you're trusting code you can't inspect with live trading access.
• Good commercial libraries cost money.

The earlier version of this post called this approach "protocol hacking" and treated it as one of only two options. It also skipped the official Python package, which for MT5 is the better default for most people.

What about hosted cloud APIs and MetaQuotes' own APIs?

There are also paid cloud services that run terminals for you and expose a REST or WebSocket API. They trade a monthly fee and a third party holding your credentials for not having to run Windows. MetaQuotes' own Manager and Server APIs are for brokers running the MetaTrader server, not for retail accounts.

How to choose

• Your strategy fits in MQL and one broker: write an EA (option 1).
• You're on MT5 and want Python: use the official package (option 2). Put a message queue between it and your strategy if you trade more than one broker, so each broker gets its own small gateway process.
• You're on MT4, or need C#, Java or Node: a bridge EA (option 3). Native MQL5 sockets avoid the DLL if you're on MT5.
• You need dozens of accounts, Linux, or no Windows box: a protocol library or cloud API (option 4), with the risks above. Use a demo account first and plan for it breaking on a terminal update.

Whichever you choose, test on a demo account first. Also handle the failures that don't throw: a connection that quietly stops delivering prices, or an order that's rejected for an unsupported filling mode. Both of those bit me with the Python gateway, and they caused more trouble than the choice of library did.

If MetaTrader's restrictions are what's pushing you away, the FIX API is the other route. See using the FIX API as a trading gateway in C# and which cTrader brokers allow FIX API for retail traders.