MQL5 OrderSend

MQL5 OrderSend is the MetaTrader 5 function used to send a trading request from an MQL5 program to the trade server. The ordersend mql5 workflow passes an MqlTradeRequest structure describing the requested operation and receives an MqlTradeResult structure containing the server response. It matters because opening positions, placing pending orders, modifying orders, closing positions, and other automated trade actions eventually depend on a correctly formed request and accurate interpretation of its result.

One detail trips up plenty of Expert Advisor developers: a true return value from OrderSend() does not necessarily mean a trade was filled. It means the request passed the function's initial handling and was accepted for further processing. Actual execution status comes from MqlTradeResult.retcode and, where execution continues after the call returns, subsequent trade events.

How the OrderSend Function MQL5 Request Works

The OrderSend function MQL5 uses two structures rather than a long list of positional arguments. MqlTradeRequest describes what should happen, while MqlTradeResult reports what the terminal or trade server did with that request. The required request fields depend on the operation and the symbol's execution model.

• action identifies the operation, such as TRADE_ACTION_DEAL for a market deal or TRADE_ACTION_PENDING for a pending order.
• symbol, volume, and type identify the instrument, requested lot size, and buy/sell order type.
• price, deviation, sl, and tp control price-sensitive execution and protective levels where applicable.
• type_filling defines the volume filling policy supported for that symbol.
• magic and comment help an Expert Advisor identify and audit its own trading activity.

A subtle production issue is type_filling. Brokers and symbols may support different filling policies, so hard-coding a policy that worked on one account can cause rejected requests elsewhere. Operators can inspect SYMBOL_FILLING_MODE with SymbolInfoInteger() and construct the request around the execution policies actually available for the instrument.

A Practical MQL5 OrderSend Example

A basic MQL5 OrderSend example initializes both structures, sets the trade action and core order fields, sends the request, and then examines both the function result and server return code. The example volume below is illustrative rather than a universal lot-size recommendation.

This sample deliberately separates transport-level success from trade-level success. In real code, don't copy ORDER_FILLING_IOC blindly; derive a compatible filling policy from the symbol and execution environment. Also validate requested volume against symbol properties such as minimum volume, maximum volume, and SYMBOL_VOLUME_STEP. A mathematically reasonable position size can still be rejected if it doesn't land on the broker's permitted volume increment.

Checking Whether OrderSend Really Succeeded

There are several layers of success, and mixing them together makes debugging messy. First inspect the Boolean returned by OrderSend(). If it is false, call GetLastError() to understand why the terminal could not complete the send operation. If it is true, inspect result.retcode; that's the trade server's response and is the more meaningful indicator of what happened to the request.

For robust automation, the trade lifecycle often continues after OrderSend() returns. A market request can trigger several events as an order is created, executed, moved to history, and reflected as a deal or position. OnTradeTransaction() is therefore useful when the strategy needs confirmation of the resulting state rather than merely confirmation that a request was submitted.

Why MQL5 OrderSend Error 4752 Appears

MQL5 OrderSend error 4752 is the runtime error ERR_TRADE_DISABLED, meaning trading by Expert Advisors is prohibited. This is different from an invalid price, volume, or stop level. In other words, rewriting the order calculation won't fix a permission problem.

Check the environment before chasing request fields. TerminalInfoInteger(TERMINAL_TRADE_ALLOWED) reports whether terminal trading is permitted, while AccountInfoInteger(ACCOUNT_TRADE_EXPERT) indicates whether Expert Advisor trading is allowed for the account. Account restrictions, terminal AutoTrading settings, or program permissions can block the request. A related server response is TRADE_RETCODE_CLIENT_DISABLES_AT, indicating automated trading is disabled by the client terminal.

A useful diagnostic pattern is to call ResetLastError() immediately before OrderCheck() or OrderSend(), then log GetLastError(), result.retcode, and result.comment separately. Otherwise an older runtime error can remain in _LastError and send you down the wrong rabbit hole.

Using OrderCheck Before Sending the Trade

OrderCheck() can validate a prepared MqlTradeRequest before it reaches normal execution. It can expose problems involving request parameters, available funds, projected margin, and related account conditions. Passing the check still doesn't guarantee execution because prices, market state, permissions, and server conditions can change between validation and processing.

That distinction matters in fast markets. Suppose OrderCheck() accepts a request, then the market closes or the quoted price becomes unavailable before OrderSend() is processed. The earlier validation wasn't wrong; the environment simply changed. Treat pre-checking as validation, not a reservation of liquidity or execution.

Moving the OrderSend Function From MQL4 to MQL5

The OrderSend function MQL4 to MQL5 migration is not a straight signature replacement. MQL4 commonly passes symbol, command, volume, price, slippage, stops, and other values directly into OrderSend(). MQL5 packages trading instructions inside MqlTradeRequest and returns richer execution information through MqlTradeResult.

The account model also matters. MetaTrader 5 can operate with netting or hedging behavior depending on the account. Code that assumes every deal creates a separate independent position can therefore behave differently after migration. Closing or modifying logic should work with MQL5's order, deal, and position model rather than treating those records as interchangeable.

Production Failure Modes Worth Watching

The raw function call is rarely the hard part. Reliable automation depends on handling broker-specific symbol settings and changing market state around it. Several faults can look like an OrderSend bug even though the request mechanism itself is fine.

• Invalid volume: calculated lots don't respect the symbol's permitted minimum, maximum, or volume step.
• Invalid filling policy: the request uses a filling mode the symbol or execution model doesn't support.
• Invalid stops: Stop Loss or Take Profit values conflict with the broker's symbol rules or current price.
• Market state changes: quotes disappear, prices move, or the market closes between calculation and request processing.
• False success assumptions: code treats the Boolean return as proof of a filled trade and updates strategy state before execution is actually confirmed.

For live Expert Advisors, log enough context to reproduce failures: symbol, action, order type, volume, requested price, filling mode, terminal error, server retcode, and server comment. That small audit trail can turn a vague "trade didn't open" report into a specific configuration or execution problem.