# Place multiple orders (TRADE)

## API Description

The burst primitive. Up to 100 orders in one signed request, **each with its own `login`** — this is
how you fan one signal out across many accounts in a single round trip.

## HTTP Request

```http
POST /v1/batchOrders
```

## Request Weight

1 per item (1 per item against `ORDERS`)

## Request Parameters

| Name | Type | Mandatory | Description |
| - | - | - | - |
| `batchOrders` | LIST\<JSON> | YES | JSON array of 1-100 order objects. URL-encode it as a single form field value. |
| `newOrderRespType` | ENUM | NO | Applies to every item. `ACK` (default) or `RESULT`. |
| `recvWindow`, `timestamp`, `signature` | | | |

Each item takes the same fields as [`POST /v1/order`](/trade/new-order.md), **including its own `login`**:
`login`, `symbol`, `type`, `side`, `volume`, `price`, `stopLimitPrice`, `sl`, `tp`, `timeInForce`,
`expiration`, `newClientOrderId`, `comment` (24 characters, same reserved-tag rule). Items do not carry `timestamp`, `signature`,
`recvWindow` or `newOrderRespType` — those are request-level.

> Sign the body **exactly as transmitted**, including the percent-encoded `batchOrders` value. Build
> the encoded string once, sign that string, send that string. Re-serialising the JSON after signing
> changes the bytes and gives `-1022`.

The whole batch is refused, with nothing queued, when `batchOrders` is missing, not an array, empty or
longer than 100 items (`-1131`), is not valid JSON or contains an element that is not an object
(`-1130`), or repeats a `newClientOrderId` (`-1132`). Everything else — a missing or invalid item
`login` (`-1102` / `-1122`), a login outside the key's scope (`-2022`), any validation or execution
error — is reported per item, in that item's slot.

`RESULT` on a large batch holds the connection for up to 5 seconds. Use `ACK` for anything
latency-sensitive.

**Example body** (before URL-encoding)

```json
[
  {"login":100123,"symbol":"XAUUSD","type":"MARKET","side":"BUY","volume":"0.10","newClientOrderId":"sig7-100123"},
  {"login":100124,"symbol":"XAUUSD","type":"MARKET","side":"BUY","volume":"0.25","newClientOrderId":"sig7-100124"},
  {"login":100125,"symbol":"XAUUSD","type":"MARKET","side":"BUY","volume":"0.05","newClientOrderId":"sig7-100125"}
]
```

## Response Example

**Response** — an array **in the same order as the request**. Each element is either a success
object (the same shape as a single order response) or an error object. A failed item does not affect
the others; the batch is **not** atomic.

```json
[
  {
    "login": 100123,
    "clientOrderId": "sig7-100123",
    "symbol": "XAUUSD",
    "side": "BUY",
    "type": "MARKET",
    "volume": "0.10",
    "status": "ACCEPTED",
    "transactTime": 1789012800100
  },
  {
    "code": -2018,
    "msg": "Insufficient margin on the trading account.",
    "mt5RetCode": 10019,
    "status": "REJECTED",
    "clientOrderId": "sig7-100124",
    "login": 100124
  },
  {
    "code": -2022,
    "msg": "Login is not in this API key's scope, or the account is not tradable.",
    "login": 100125
  }
]
```

Match results to requests **by index**, or by `clientOrderId` — which is why each item should carry
a distinct one. The HTTP status is `200` whenever the batch itself was accepted, even if every item
failed. A `4XX` on the batch means the batch was rejected as a whole (bad signature, malformed
array, over 100 items) and **no** item was queued.