Skip to main content
GET /api/v1/trading/requests/{request_id} retrieves the MT5 result of an opening or closing order submitted with the same token. The account verification must also remain active. The ID comes from answer.id or answer.ID in the submission response.
12345 is an example request ID, not a position ticket.

​
Persistent collection and repeat queries

The API collects MT5 events in background batches on the same physical connection that submitted the request. Client GETs read the saved result from the database; they do not consume MT5 events. Submission returns its ID without waiting for execution. There can be a short delay before the collector saves the result.
  • 200: saved final result, including rejection or partial execution. Check MT5 codes.
  • 202: {"status":"pending","request_id":1586,"result":null}. Wait at least the Retry-After interval (currently one second), then repeat only this GET.
  • 409 with TRADE_RESULT_UNAVAILABLE: no final result was retained. An optional result contains the last public snapshot. Reconcile positions/orders; never automatically resubmit the order.
  • 409 with TRADE_RESULT_AMBIGUOUS: MT5 reused an ID across sessions for this token. Reconcile instead of guessing the operation.
A saved final result remains queryable after restart while the token and account verification remain valid. Results consumed before this feature was deployed are not recoverable through this cache. A crash between consuming and persisting an event can still lose it; unavailable does not mean the trade failed.

​
Confirmation process

  1. Keep the submission response associated with the intent and its idempotency key.
  2. Query the ID using the token that created it.
  3. Inspect the MT5 result: a successful HTTP response does not imply execution.
  4. If the result is still inconclusive, wait before querying again. Use a configurable interval, respect your token’s limit, and set a local deadline.
  5. When MT5 confirms execution or rejection, query positions and orders to reconcile the actual effect on the account.
  6. If your deadline expires without confirmation, mark the intent as uncertain and contact support.
The response uses an explicit allowlist of public fields. It preserves retcode and answer; ID-grouped events retain their structure only for the requested ID. Flat results and event lists are also supported. Missing fields are omitted; no status or value is invented. The result event allows ID, Retcode, DealID, OrderID, Volume, and Price. Flat results also allow ResultRetcode, ResultDeal, ResultOrder, ResultVolume, and ResultPrice. The answer event allows IDClient, Symbol, Type, TypeFill, Volume, PriceOrder, Position, and those five Result* fields. Account logins, Manager login, IP, comments, gateway data, extended volumes, ApiData, and unknown fields are excluded. Volume in the answer event is the requested volume; ResultVolume is the reported executed volume. Request, order, and deal IDs are not position tickets. Query positions to reconcile execution.

​
Cases requiring attention

  • A 403 with Trade request not owned by this token means the ID is not registered for that token. Another token cannot retrieve the original request.
  • An expired verification must be renewed to continue querying the account.
  • A timeout while querying the result allows you to repeat the GET query; it does not mean you should resubmit the opening or closing order.
  • If you did not receive the ID, there is no partner lookup by idempotency key. Reconcile the account and escalate if you cannot determine what happened.
Follow the recovery procedure for uncertain results.