# 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](/changelog.md)) 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`](/trade/new-order.md) (pending types),
[`PUT /v1/order`](/trade/modify-pending-order.md),
[`DELETE /v1/order`](/trade/cancel-pending-order.md),
[`PUT /v1/position`](/trade/modify-position-sltp.md), 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`](/trade/close-position.md) and each
  [`DELETE /v1/allOpenPositions`](/trade/close-all-open-positions.md) 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`](/user-data-streams/order_update.md) and
[`POSITION_UPDATE`](/user-data-streams/position_update.md) on the user data stream, or
[`GET /v1/openOrders`](/trade/current-pending-orders.md) and
[`GET /v1/positions`](/trade/open-positions.md). 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`](/trade/new-order.md) and
[`POST /v1/batchOrders`](/trade/place-multiple-orders.md) 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](/trade.md#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`](/trade/modify-pending-order.md),
[`DELETE /v1/order`](/trade/cancel-pending-order.md) and
[`GET /v1/order`](/trade/query-order.md) 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`](/trade/cancel-pending-order.md).

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`](/account/account-trade-list.md) 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`](/user-data-streams/deal.md) 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`](/market-data/exchange-information.md).
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).