MT5 v2 gets market data, and ticks can now arrive in batches
In September I wrote that MT5 v2 was not a replacement for v1 yet: it had twelve endpoints, all reads and partial updates, and no market data at all. That last part was the one that mattered, because a chart cannot be built on user records. It is fixed.
Bars, from minutes to days
GET /api/v2/MT5/{tradePlatform}/ChartRequest/{symbol} returns OHLC bars for a symbol and a window: open, high, low, close, tick volume, real volume, and the lowest spread inside the bar.
The trading server stores minute bars and nothing else — MetaTrader builds every other timeframe on the client, and that is still true. What the endpoint adds is period: ask for M5, M15, M30, H1, H4 or D1 and the aggregation happens on our side, on the boundaries of the server's own clock. A day starts at 00:00 of the trading server, not at midnight UTC, because that is how the platform counts a day.
from and to are optional, limit caps the answer and sets truncated when it did. If the platform has not pulled the requested history from its history server yet, the call answers MT_RET_OK_NONE and says so — repeat it in a minute instead of reading it as "no data for this symbol".
Historical ticks
GET /api/v2/MT5/{tradePlatform}/TicksHistory/{symbol} returns the platform's tick history: millisecond timestamp, bid, ask, last, volume, and the flag bits as names.
from is required here, which is a deliberate asymmetry with bars. Ticks are thousands of times denser; a request with no start scans everything ever stored on the history server, and I watched one take longer than the call deadline on a real platform. Refusing it with an explanation beats returning a timeout.
Both endpoints answer in the trading server's time, not UTC, and neither carries an offset. That is a property of the platform, not a shortcut: the time zone is configured per server, and daylight saving follows the operating system of that server. The offset is readable through TimeGet and TimeServer, and it has to be applied on your side before anything is stored as UTC.
Live ticks on the v2 hub
/hubs/mt5/v2 now delivers ticks: connect with ?tradePlatform={guid}, then SubscribeToTicks(symbol) and handle OnTick, or consume StreamTicks(symbol?) as an async stream. Until now the v2 hub carried connection status and margin-call updates only, and every tick integration had to stay on v1.
Batching, on all four hubs
The part I am more pleased with is not the data, it is the arithmetic. One message per tick is a message per tick: at a few hundred ticks a second a browser spends its time on frames, not on drawing.
So there is now a second subscription mode. SubscribeToTicksBatch(symbol, intervalMs, maxBatchSize) collects ticks and sends them as one array in OnTicksBatch, either when the oldest tick has waited intervalMs (200 ms by default) or as soon as maxBatchSize ticks have piled up (200 by default). Bounds are 20–60 000 ms and 1–10 000 ticks; anything else is rejected rather than silently clamped.
A batched subscriber receives OnTicksBatch only — no OnTick alongside it. It is available on all four hubs: MT4 and MT5, v1 and v2.
One bug I found on the way
While wiring the v2 ticks I found that SubscribeToTicks on the MT4 v2 hub had never delivered anything. The subscription was recorded, the group was created, and no code ever published into that group — the v1 context was the only publisher, and a v2 group is invisible to it. Anyone who had tried the callback model on /hubs/mt4/v2 saw silence and probably concluded their client was broken. It publishes now. StreamTicks on the same hub was always fine.
Where it is
Staging today, production within days. The four SDKs are already at 0.3.4 with the new endpoints and the batch methods, so npm i @mywebapi.com/sdk, pip install mywebapi-sdk, MyWebApi.Sdk on NuGet and the MyWebApi PowerShell module all carry it.
If you are building a chart on top of this and something does not add up, write to me — the time-zone handling is the part I would most like a second pair of eyes on.