Known Limitations

This API is pre-launch. The other pages describe the contract — the behaviour you should build against. This page lists where the service currently falls short of that contract, as observed in the first session against the new MT5 trade server on 2026-10-08. Each entry says what you will see, which endpoints it affects, and what to do until it is fixed. Entries are removed (and the removal noted in the changelog) as fixes land; nothing here changes a field, an enum or an error code.

The trade server sends no dealer answer

Affects: POST /v1/order (pending types), PUT /v1/order, DELETE /v1/order, PUT /v1/position, and every rejection.

The current trade server does not return an answer to the requests this API sends. The service therefore learns an outcome only from what the trade server records:

• Market orders and closes still settle. A market POST /v1/order, a DELETE /v1/position and each DELETE /v1/allOpenPositions leg produce a deal, the deal is picked up from the deal stream, and the order settles to FILLED — inside the 5-second RESULT wait when the deal arrives in time.
• Operations that create no deal stay at their queued status. A pending placement or a PUT /v1/order keeps NEW; a DELETE /v1/order or a PUT /v1/position keeps ACCEPTED. The response arrives after the 5-second wait with that status and no mt5RetCode.
• A rejection is not reported as REJECTED. A request the trade server refuses (insufficient margin, invalid stops, market closed…) stays ACCEPTED / NEW instead of returning the mapped error with its mt5RetCode.

What to do: confirm every non-market operation from the account state, not from the response — ORDER_UPDATE and POSITION_UPDATE on the user data stream, or GET /v1/openOrders and GET /v1/positions. Do not resend with a new newClientOrderId because a response says ACCEPTED.

NEW on a pending placement means "queued", not "resting"

Affects: POST /v1/order and POST /v1/batchOrders items with a pending type.

A pending order is reported NEW from the moment it is durably queued — on an ACK response and on a RESULT response that timed out alike (see Status values). With no dealer answer from the current server, that is the only status a placement ever reports. Until the order shows up on the book, NEW does not prove it is there: confirm it with GET /v1/openOrders or an ORDER_UPDATE event carrying its orderId.

Modify / cancel / query by origClientOrderId does not find a pending order

Affects: PUT /v1/order, DELETE /v1/order and GET /v1/order when called with origClientOrderId for a pending order.

Because the placement never receives an answer (above), the service never learns the order ticket the trade server assigned to it. PUT and DELETE by origClientOrderId therefore answer -2013, and GET /v1/order?origClientOrderId= reports the stored queued status rather than the live state of the order on the book.

What to do: address pending orders by orderId. Take it from the o field of the ORDER_UPDATE event or from GET /v1/openOrders. PUT /v1/order by orderId works.

Cancelling a pending order currently fails on the trade server

Affects: DELETE /v1/order.

On the current server a cancel is not applied: the order stays on the book and the response never reaches CANCELED. Check GET /v1/openOrders before assuming an order is gone, and contact the broker if an order must be removed urgently.

GET /v1/userTrades is empty on staging

Affects: GET /v1/userTrades in the sandbox / staging environment.

The broker-side deal-history sync that this endpoint reads from is not running on staging, so the endpoint returns [] there even after trades. Use the DEAL events on the user data stream to record executions while testing.

Server time zone

Not a defect, but observed on the first live session: the current trade server reports serverTimeZoneOffsetMinutes: 180 (UTC+3) on GET /v1/exchangeInfo. Symbol sessions are in that zone. Always read the offset from exchangeInfo rather than hard-coding it — it can change (for example with daylight saving on the server).