Place one order across many MT5 accounts

A multi-account order places one trade on many MetaTrader 5 accounts at the same moment — a signal service entering for every subscriber, a fund manager trading a set of managed accounts, a copier fanning out a master's trade. You make one request; every account gets its own order, sent together.

In the API these are called execution waves (/v1/execution-waves).

POST /v1/execution-waves            one trade, many accounts → 201 at once
GET  /v1/execution-waves/{id}       poll until state = settled
GET  /v1/orders/{orderId}           any one account's order, in full
POST /v1/execution-waves/{id}/close close what it opened, every account at once
POST /v1/execution-waves/{id}/retry a new one for the accounts it did not reach

The requestCopy Anchor Link

curl -sS -X POST "https://api.fxapis.com/v1/execution-waves" \
  -H "Authorization: Bearer $FXAPIS_KEY" \
  -H "Idempotency-Key: wave:signal_9931" \
  -H "Content-Type: application/json" \
  -d '{
    "accountIds": [
      "0d7c1f5e-4b6a-4c1e-9f0a-2d9e8c7b6a51",
      "5b2e8a10-93c4-4f7d-8e61-0a9c2b4d6e13",
      "c41d7e22-6f0b-4a95-b3e8-7d1f5a2c9b80"
    ],
    "symbol": "EURUSD",
    "side": "buy",
    "volume": "0.01",
    "weights": { "5b2e8a10-93c4-4f7d-8e61-0a9c2b4d6e13": "0.05" },
    "stopLoss": "1.12900",
    "takeProfit": "1.14200",
    "barrierPolicy": "release-ready",
    "label": "London open — EURUSD long",
    "clientWaveId": "signal_9931"
  }'

The response is 201 straight away, with the order in state planned and one entry per account in legs. The work happens in the background: poll GET /v1/execution-waves/{id}. Reference: Place one trade on many accounts.

Multi-account orders are a plan feature; a plan without them answers 402 FEATURE_NOT_IN_PLAN, and a request larger than the plan allows answers 402 QUOTA_EXCEEDED before anything is created.

Accounts at different brokers: name an instrumentCopy Anchor Link

Brokers name the same market differently — gold is XAUUSD.a at one, GOLD at another, XAUUSDm at a third. Send instrument instead of symbol and each account trades its own broker's symbol for it:

{
  "accountIds": ["…", "…", "…"],
  "instrument": "XAUUSD",
  "side": "buy",
  "volume": "0.10"
}

Each account's symbol is worked out once, when the order is made, and shown on its leg (legs[].symbol); the order itself has symbol: null and instrument: "XAUUSD". If any account cannot trade the instrument, nothing is placed: the request is refused with 422 INSTRUMENT_UNAVAILABLE, and details names each account and why — INSTRUMENT_NOT_OFFERED, INSTRUMENT_AMBIGUOUS (with candidates), or SYMBOLS_NOT_SYNCED for an account that has never been online. Bring that account online once, or leave it out, and send again.

Sizing with weightsCopy Anchor Link

weights values are volumes, not multipliers. With "volume": "0.01" and "weights": {"B": "0.05"}, account B trades 0.05 lots and every other account trades 0.01.

A common way to size by account balance is to compute each account's lots on your side and send them all as weights:

from decimal import Decimal, ROUND_DOWN

def lots_for(balance: Decimal, reference_balance: Decimal, reference_lots: Decimal) -> str:
    raw = reference_lots * balance / reference_balance
    lots = raw.quantize(Decimal("0.01"), rounding=ROUND_DOWN)   # the symbol's volume step
    return str(max(lots, Decimal("0.01")))                      # at least the minimum

Use Decimal (or your language's decimal type) and send strings. Round down to the symbol's volume step — rounding up quietly increases every account's risk. A weight that is not a usable volume is refused with 400 INVALID_REQUEST naming the account.

Bring the accounts online firstCopy Anchor Link

Each account's order can only be sent while that account is online, and a broker login takes about ten seconds in our tests. A multi-account order brings offline accounts online itself: with no executeAt, it waits for them — up to 60 seconds — and sends to everyone together as soon as they are all ready (or as soon as the only ones left need a person, such as a wrong password). After the minute, the barrier policy decides about the stragglers: skipped (release-ready), waited for until expiresAt (wait), or the whole order held (all-or-nothing).

When the moment matters — a signal whose price will not wait a minute — bring the accounts online before you create the order, and wait until they are ready:

session.post(f"{API}/v1/accounts/prepare", json={"accountIds": account_ids})   # up to 200 per call
# poll GET /v1/accounts/{id}/status until "ready" for each, as in the language guides

Then create the multi-account order with executeAt at the moment you want to enter, or without it to send as soon as every account is ready. See Signals → prepare. For accounts that must act at any moment, the always_on mode keeps them online all the time — see Accounts → Modes.

Barrier policiesCopy Anchor Link

The barrier is the moment the orders are released. barrierPolicy decides what happens when some accounts are not online at that moment:

all-or-nothing is about sending, not about the result. A broker can still reject one account's order after all were sent — for margin, say — and no API can make a hundred independent brokers fill as one transaction.

If expiresAt passes and the policy still will not send, the order ends abandoned with nothing sent. With release-ready or wait, reaching expiresAt sends to whichever accounts are ready.

Following it to the endCopy Anchor Link

import time

def follow(wave_id, timeout=300):
    deadline = time.monotonic() + timeout
    while time.monotonic() < deadline:
        wave = session.get(f"{API}/v1/execution-waves/{wave_id}").json()["data"]
        if wave["state"] in ("settled", "cancelled", "abandoned"):
            return wave
        time.sleep(1)
    raise TimeoutError(wave_id)

wave = follow(wave["id"])
print(wave["state"], wave["summary"], f"spread {wave['dispatchSpreadMs']} ms")
for leg in wave["legs"]:
    print(leg["accountId"], leg["state"], leg["volume"], leg["orderId"], leg["stateDetail"])

The order moves planned → preparing → armed → releasing → settled: accepted, bringing accounts online, waiting for the moment, sending, and every account has a result. cancelled and abandoned mean nothing was sent.

{
  "state": "settled",
  "dispatchSpreadMs": 30,
  "summary": { "total": 100, "filled": 97, "partiallyFilled": 1, "rejected": 2, "skipped": 0, "unresolved": 1 }
}

partiallyFilled counts the accounts, among the filled ones, whose order filled only in part. Each leg shows the same with partiallyFilled (true or false) and filledVolume, how much its order filled.

A multi-account order never reports a single success or failure. Each leg has its own state:

Each leg's order is an ordinary order: it appears in GET /v1/orders, is confirmed against the broker like any other, and is closed like any other — with POST /v1/accounts/{id}/positions/{ticket}/close, account by account, or all at once.

Scheduling with executeAt and expiresAtCopy Anchor Link

{
  "executeAt": "2026-10-01T07:00:00Z",
  "expiresAt": "2026-10-01T07:00:30Z",
  "barrierPolicy": "release-ready"
}

The orders are sent at executeAt, not before — even if every account is ready early. Bring the accounts online first, as above, so they are ready when the moment comes. Times are RFC 3339; use UTC. A warm_on_demand account goes offline after 15 idle minutes, so for an executeAt further ahead than that, prepare the accounts shortly before it, or use always_on for them.

CancellingCopy Anchor Link

curl -sS -X POST "https://api.fxapis.com/v1/execution-waves/$WAVE_ID/cancel" \
  -H "Authorization: Bearer $FXAPIS_KEY"

Possible only before anything is sent: a scheduled order waiting for its executeAt, or one waiting for accounts. Once orders are going out, cancelling returns 409 WAVE_ALREADY_RELEASING — an order that has left for a broker cannot be recalled, and cancelled would claim that nothing was sent.

Closing what it openedCopy Anchor Link

curl -sS -X POST "https://api.fxapis.com/v1/execution-waves/$WAVE_ID/close" \
  -H "Authorization: Bearer $FXAPIS_KEY" \
  -H "Idempotency-Key: close:signal_9931"

Closes, on every account at once, the position each filled account's order opened: the order's brokerPositionId, or its brokerOrderId until that is set. Each close is an ordinary close order, exactly like closing one position: never refused for your plan's allowance, refused while trading is switched off. Send {"accountIds": ["…"]} to close only some accounts. It needs the trading:reduce scope, and the order must have ended; before that it answers 409 WAVE_NOT_ENDED.

An Idempotency-Key is required. A repeated close does not close twice: it opens opposing positions. Each account's close is keyed from yours, so sending the same key again answers with the first result (idempotent-replay: true) and sends nothing.

The answer has a result for each account:

Retrying the accounts it did not reachCopy Anchor Link

curl -sS -X POST "https://api.fxapis.com/v1/execution-waves/$WAVE_ID/retry" \
  -H "Authorization: Bearer $FXAPIS_KEY" \
  -H "Idempotency-Key: retry:signal_9931" \
  -H "Content-Type: application/json" \
  -d '{ "barrierPolicy": "release-ready" }'

Places a new multi-account order for the accounts that were skipped: the same market, side, per-account volumes, stops and comment. The body is optional:

A cancelled or abandoned order sent nothing, so every account is retried. An unresolved account is never retried: it may have executed. The new order is checked like any new one (plan, accounts, the key's limits, the rate limit), and the two are linked: the new one's retryOf is the original, and the original's retriedBy lists the new one. It needs an Idempotency-Key: the same key again returns the same new order, 200 with idempotent-replay: true. Before the original has ended it answers 409 WAVE_NOT_ENDED, and 409 NOTHING_TO_RETRY when no account matches.

Dispatch spreadCopy Anchor Link

dispatchSpreadMs is the time between the first account's order being sent and the last. It is the number to watch: as it grows, your accounts are getting different prices. Every multi-account order reports its own; these are from our benchmark against an instant broker, so a real broker adds its own latency on top:

Measured on our side against a broker answering instantly. Each broker adds its own latency on top — about 100 ms for a round trip to a London broker — and brokers fill at their own prices, so fills across accounts are close but never identical.

Retrying safelyCopy Anchor Link

Send an Idempotency-Key with every multi-account order. Sending the same key again returns the order that key created — 200 with idempotent-replay: true — rather than creating a second one, which would be a duplicate trade on every account at once. Use one key per decision, such as wave:signal_9931. See Idempotent MT5 orders.

Creating, retrying and cancelling multi-account orders has its own rate limit per workspace — 10 a minute with a burst of 2 — separate from single orders and reads (closing what one opened counts as trading, like any close); a 429 RATE_LIMITED carries retry-after. See Errors.

RelatedCopy Anchor Link

• Build an MT5 trade copier — multi-account orders as the fan-out.
• Signals and click-to-trade — when each member approves their own trade instead.
• Trading → Multi-account orders and the API reference.