An order request asks for a price-side action and a volume. The market may not be able to execute the entire volume immediately. MT5 filling modes determine what happens in that situation: refuse an incomplete fill, accept the available amount and cancel the remainder, or leave a remainder working where permitted.
Those choices are separate from buy versus sell, market versus pending, and a deviation setting. Understanding them helps explain partial executions and unsupported-policy errors. This guide also distinguishes native MT5 controls from the smaller public MetaKit REST schema, so an integration does not depend on an override the API does not offer.
FOK, IOC and Return in one example
Assume a synthetic request for 1.00 lot and a situation where only 0.40 lot can immediately satisfy the applicable execution conditions. The conceptual outcomes are:
| Policy | Immediate execution | Unfilled 0.60 lot |
|---|---|---|
| Fill or Kill, FOK | None if the full request cannot be satisfied | The request is not partially executed |
| Immediate or Cancel, IOC | Up to the available 0.40 lot | The unfilled part is canceled |
| Return, where allowed | A partial execution can occur | The remaining volume can continue working |
MetaQuotes documents these policies in its execution and filling chapter. FOK can be satisfied through more than one available offer; it does not imply a single counterparty or a single displayed price level. The table is a simplified illustration, not a prediction of how a particular broker will execute a real request.
Keep price protection separate. A volume policy says what to do with unfilled quantity. It does not by itself promise a particular fill price, guarantee zero slippage or override the broker's execution rules. The slippage guide discusses the difference between an expected price and an actual fill.
Broker settings constrain the choice
Native MT5 distinguishes an execution mode from allowed filling policies. The symbol's filling permissions are represented by flags; the order request selects a policy. Those identifiers should not be copied into each other as though they were the same enumeration.
The order-properties reference explains compatibility, including the restriction on Return for Market Execution. Pending orders have their own documented handling: the native guidance specifies Return for placement, with eventual execution governed by the relevant rules.
This is why changing a number until an order is accepted is a poor diagnostic. First establish whether the request is immediate or pending, which execution mode the symbol uses, and which policies are supported. A rejection can reflect an invalid combination rather than insufficient balance or a malformed stop.
Do not generalize from one broker's demo symbol to every live account using the same symbol name. Contract and execution settings belong to the actual account/server/instrument combination. A supported native workflow also does not prove that every third-party API exposes all of its controls.
What MetaKit exposes today
The current public POST /v1/accounts/{id}/orders schema accepts fields including symbol, side, type, volume, optional prices/stops, deviation, comment and expiration. It does not expose a type_filling or filling_mode override. The public symbol-detail response likewise does not include all native execution and filling properties.
The terminal adapter currently chooses FOK when the symbol's flags allow it, otherwise IOC when allowed, otherwise Return. That is an implementation selection rule, not a configurable REST feature or a guarantee that every broker/request combination is valid. The same helper is currently used for pending placement, so do not assume that it independently implements the native pending-order Return rule.
If your integration requires an explicit policy or encounters a broker-specific incompatibility, the present public API provides no override for that requirement. Gather the request context and returned retcode, consult support, and validate the documented behavior before relying on the workflow. Do not invent a JSON property and infer acceptance from the absence of an error about that property.
This article does not change or endorse the adapter's policy selection. It describes the current boundary so you can evaluate whether the API meets your execution needs. The order-placement walkthrough covers the supported request sequence, while the API reference documents the public fields.
A successful response can still require quantity reconciliation
MetaQuotes defines retcode 10010 as TRADE_RETCODE_DONE_PARTIAL in its trade-server return codes. The current MetaKit terminal adapter treats that retcode as a successful result. The market-order route can therefore return status: "filled" for a partial success, alongside the returned volume and retcode.
Do not interpret the status word alone as proof that the requested quantity executed. Persist the requested volume separately from the returned result, then reconcile with deals and current positions. If a response field is absent or inconsistent, keep an unresolved state rather than filling the gap with the originally requested size.
In the synthetic 1.00-lot IOC example, a confirmed 0.40-lot execution leaves 0.60 lot unexecuted. That residual is arithmetic, not authorization to submit another order. Price, risk limits and strategy intent may have changed since the first request. A second request is a new decision with its own exposure consequences.
For an illustrative linear contract with 100,000 base units per lot, 0.40 lot represents 40,000 base units and the unexecuted 0.60 represents 60,000. Using 1.00 lot in subsequent risk reporting would overstate the executed amount by 60,000 units. Contract sizing still comes from the actual symbol specification; those numbers are assumptions for the example.
Keep unknown outcomes separate from partial outcomes
A confirmed partial execution has evidence of some executed quantity. A network timeout means the outcome may not yet be known. Treating both as “send the missing amount” can duplicate exposure because the missing amount after a timeout has not been established.
Use the documented idempotency mechanism and reconcile before making another execution decision. Repeating the same request key is not a method for topping up a partial fill; it replays the recorded outcome according to the API's contract. The idempotency guide covers that distinction.
A useful read-only audit record contains the original intent id, requested quantity, response quantity, status, retcode, order/deal identifiers and the later reconciled state. Preserve the raw response. Do not overwrite requested volume with executed volume and lose the ability to explain the discrepancy.
The worked volume arithmetic and the public field mappings were checked without sending any orders. Before a production dependency on filling behavior, validate the supported contract with the provider and your broker. If the required controls are unavailable, recognize that as an integration limitation rather than assuming all native MT5 features are reachable through REST.
Sources and verification
Verified 19 October 2026 against MetaKit's public order schema, result mapping and terminal filling helper. No live or demo trades were placed.
- MetaQuotes execution and filling chapter, policy semantics.
- MetaQuotes order properties, compatibility and native fields.
- MetaQuotes trade return codes, confirmed partial-execution code.
- MetaKit API reference, supported REST request surface.