# MtApi: driving MetaTrader from .NET through a WebSocket bridge

> MtApi gives .NET applications a way to call MQL functions inside a running MetaTrader terminal, by pairing a C# client with a C++ connector and an Expert Advisor that lives on the terminal's charts. It is a Windows-only, Visual Studio build with MSI installers, and it explicitly does not connect to MT servers on its own.

**vdemydiuk/mtapi** — MetaTrader API (terminal bridge)

- Repository: https://github.com/vdemydiuk/mtapi
- Stars: 704 · Forks: 331
- Language: C#
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/vdemydiuk-mtapi

## A bridge, not a broker connection

MtApi provides a .NET API for working with the MetaTrader platform. The README is careful about what that means, and the second sentence is the one to read before anything else: it is not an API for connection to MT servers directly. MtApi is just a bridge between the MT terminal and .NET applications designed by developers.

That distinction determines the whole architecture. The API works by executing MQL commands and functions through an Expert Advisor linked to a chart of MetaTrader. Most of the API's functions duplicate the MQL interface, which is why a .NET developer can call trading functions they already know from MQL, and why the API surface is wide rather than narrow.

The communication layer was designed with the WebSocket framework in mind, with the stated intention of using the flexibility to set up connections. The project supports two types of connection to the MetaTrader terminal, local and remote via TCP, and the port of connection is defined by the MtApi expert, so the developer chooses it when configuring the advisor in the terminal.

The practical implication is that a trading server, an account, a running terminal and an expert on a chart are all prerequisites. MtApi is a way to automate and monitor a terminal you already operate, not a way to build a new execution venue.

## The four layers between your code and the terminal

The project structure section describes the pipeline in enough detail to reason about it, and it is worth following layer by layer because every deployment problem eventually lands in one of them.

MtService is the common engine communication project of the API, and it contains the server side implementations based on WebSocket, from the Boost library. MtClient is the client side communication project, based on WebSocket, written in C#. MTConnector and MT5Connector are the libraries that work as a proxy between the MQL and C# layers, and they provide the API interfaces for working with MQL experts.

Above that sit MtApi and MtApi5, the client side libraries that are used in user projects. These are the assemblies your own code references, and they come in two flavours because MT4 and MT5 expose different MQL dialects and the connector in between is not the same code. The repository has separate MTConnector/ and MT5Connector/ directories, and separate MtApi/ and MtApi5/ directories, and the sample code imports the namespace that matches the terminal you are on.

The Expert Advisors are the part that lives inside MetaTrader. They are MT4 and MT5 .ex4 and .ex5 files linked to the terminal's charts, and they execute the API's functions and provide trading events back to the .NET side. The mq4/ and mq5/ directories hold the MQL sources, and the README notes that the MQL files have been pre-compiled to .ex4 files in the repository.

So the request path is: your C# calls MtApi, MtApi sends a WebSocket message, the connector translates it into an MQL call, the expert on the chart executes it inside the terminal, and the result travels back the same way. Four languages, three processes, one chart.

## Building the solution from Visual Studio

The build instructions are unusually specific, and that is a hint about what kind of project this is.

The project is supported by Visual Studio 2022 and is based on .NetCore, described as .Net 8. It requires HeatWave for VS2022, the set of tools for creating WiX installation packages, and the instruction is simply to install the VS extensions. MQL files are worked on with MetaEditor, the separate toolchain for the MQL language.

The build itself branches on the target platform. For MT4 you choose the x86 configuration and start with building MtApiInstaller, which builds all the projects related to MT4: MtApi, MtClient, MtService and MTConnector. For MT5 you choose x64, or x86 for the 32-bit MT5, and start with MtApi5Installer, which builds MtApi5, MtClient, MtService and MT5Connector. The architecture difference is not arbitrary: the terminal itself is 32-bit for MT4 and 64-bit for MT5, and the connector has to match the process it injects into.

The outputs are laid out predictably. All binaries go to the build directory in the project root, the .msi installers land under build/installers/, and the .dll libraries go into the bin/ directory. The Boost libraries are precompiled for x64 and x86 and sit in the thirdparty directory.

There is one extra build step for anyone changing the Expert Advisor. Changing the source code of the MQL expert advisor requires recompilation with MetaEditor, and before recompiling you have to place two MQL library files, hash.mqh and json.mqh, in the MetaEditor include folder, which is usually located at the path shown in the README:

```text
C:\Users\<username>\AppData\Roaming\MetaQuotes\Terminal\<terminal-hash>\MQL5\Include\.
```

The presence of hash.mqh and json.mqh tells you the wire format between the connector and the expert is a JSON payload with a hash, and the two library files have to be present on the terminal side for the advisor to compile.

## Installing with the MSI and the missing redistributable

Installation is done with the installers, and the README says they set up all the libraries automatically. For MT4 the artefact is MtApiInstaller.msi, and for MT5 it is MtApi5Installer_x64.msi. The MT5 build is architecture specific in the same way the build is, since the connector has to match the terminal process.

The detail that catches people is the additional packet requirement. The VCRedist packet must be installed for the connectors, MTConnector or MT5Connector, to work correctly, and the README points at the Microsoft documentation for the required installers. A connector that fails to load at runtime with a missing runtime error is almost always this, and it is a separate install from the MSI.

Two other orientation points are useful before you install. To navigate quickly to the trading platform data folder, you click File then Open data folder in the MetaTrader terminal, and the .ex4 and .ex5 advisors are looked for inside that tree, in the Experts folder where the terminal loads them from. And because the port of connection is defined by the MtApi expert, the port is a parameter you set in the terminal when you attach the advisor to a chart, not a setting in your .NET configuration.

That ordering matters for the first run: install the redistributable, install the MSI, open the terminal, attach the expert to a chart with the port you want, and only then point your application at that port.

## What the C# client looks like in practice

The console sample in the README shows the shape of a real client, and the first thing it does is set up an event-driven connection rather than a blocking call. The client type is instantiated once, and a connection state handler is subscribed that switches on the connection status and signals a wait handle when the state becomes connected, disconnected or failed:

```C#
using System;
using System.Threading;
using System.Threading.Tasks;
using MtApi5;

namespace MtApi5Console
{
    class Program
    {
        static readonly EventWaitHandle _connnectionWaiter = new AutoResetEvent(false);
        static readonly MtApi5Client _mtapi = new MtApi5Client();
```

The main routine subscribes the event handlers and then starts the connection on a port, waiting on the handle before deciding what to do:

```C#
            _mtapi.BeginConnect(8228);
            _connnectionWaiter.WaitOne();

            if (_mtapi.ConnectionState == Mt5ConnectionState.Connected)
            {
                Run();
            }
```

The port in that snippet is 8228, and it is the port the expert is expected to be listening on. The structure generalises: the client exposes BeginConnect, a ConnectionState property, and events for connection state changes, quotes added, quotes removed and quotes updated, each carrying a quote with an instrument, a bid and an ask. The examples directory in the repository holds MatLab, MtApi5Samples and Python examples, which is a reminder that the consumer of the API is not restricted to C#, only the client library is.

## Where this bridge stops working

The first limitation is the one the project states: this is not a connection to MT servers. Any architecture that wants to run its own matching engine, run headless, or connect without a desktop session running a chart is out of scope, because the terminal and the expert attached to a chart are the execution environment.

The second limitation is platform. The build is Visual Studio 2022 with WiX installers, the redistributable requirement is a Windows component, and the connector is a native library that has to load into the terminal process. The repository layout is a .sln file with WiX projects, a vcredist directory and Windows installer artefacts, and there is no cross-platform build described anywhere in the documentation.

The third limitation is the dependency on the terminal's own state. If the terminal is closed, the expert is not attached, the chart is not open, or the account is not logged in, calls do nothing useful, and the failure surfaces as a connection state rather than as a trading error. A production system built on this has to supervise the terminal as carefully as it supervises the strategy.

The real alternative is the other direction. If you want programmatic access to a broker's market data and order routing without a terminal in the loop, most brokers and data providers expose a native REST or streaming API, and the broker's own Python or .NET SDK will do the job with fewer moving parts. The difference in approach is exactly the point of this project: MtApi is a bridge into a terminal so that MQL code, including the vast body of existing MQL libraries and indicators, can be driven from a .NET application. If you do not have MQL code or a terminal workflow to preserve, that bridge is a liability rather than a feature, and a direct broker API is the better choice.

## Conclusion

Adopt MtApi if you run a MetaTrader terminal on a Windows machine and need your own C# or other .NET code to read quotes, place orders or call MQL functions that only exist inside the terminal. Do not adopt it if you want a server to talk to a broker directly, because the project states plainly that it is not an API for connecting to MT servers, and do not adopt it for a cross-platform service, since the build is Visual Studio 2022 with WiX installers on .NET 8. Before you start, confirm you can run the Expert Advisor inside a real terminal with a chart, because every call in the API is executed by that advisor, and read the connection section of the documentation to understand whether the terminal is on the same machine or reachable over TCP.

## FAQ

### What is MtApi?

MtApi is a .NET API for working with the MetaTrader platform, and it is a bridge between the MT terminal and .NET applications rather than a direct connection to MT servers. It executes MQL commands and functions through an Expert Advisor linked to a chart of MetaTrader, and most of its functions duplicate the MQL interface.

### How do I install MtApi?

Use the installers, which set up all the libraries automatically: MtApiInstaller.msi for MT4 and MtApi5Installer_x64.msi for MT5. The VCRedist packet must also be installed for the connectors to work correctly, and the expert advisors are loaded from the terminal's data folder.

### How does the MtApi connection work?

MtApi provides two types of connection to the MetaTrader terminal, local and remote via TCP, and the port of connection is defined by the MtApi expert. The layers are a C# client library, a native connector that acts as a proxy between the MQL and C# layers, and an Expert Advisor running on a terminal chart, with WebSocket carrying the messages.

### What do I need to build MtApi from source?

Visual Studio 2022 with the HeatWave extension for WiX packaging, a C compiler, and MetaEditor for the MQL sources. For MT4 you build the x86 configuration starting from MtApiInstaller, for MT5 the x64 configuration starting from MtApi5Installer, and changing the expert advisor source additionally requires hash.mqh and json.mqh in the MetaEditor include folder.

### Is MtApi still maintained?

The repository is not archived and the last push was on 2026-09-30. Recent releases are v2.0.1 from 2026-09-08, v2.0.0 from 2024-11-12 and MT4-v1.0.43 from 2020-12-20, and the project is MIT licensed.

## Sources

- [Issues](https://github.com/vdemydiuk/mtapi/issues)
- [License: MIT](https://github.com/vdemydiuk/mtapi/blob/master/LICENSE)
- [README](https://github.com/vdemydiuk/mtapi/blob/master/README.md)
- [Releases](https://github.com/vdemydiuk/mtapi/releases)
- [vdemydiuk/mtapi on GitHub](https://github.com/vdemydiuk/mtapi)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/vdemydiuk-mtapi