Operation Type (for Signing)
| Header Field | Type | Content |
|---|---|---|
| None | - | Batch orders are not signed as a whole, but rather by its individual actions components. |
Request Body
| Field | Type | Need | Description | Example |
|---|---|---|---|---|
”actions” | array | required | List of order actions to perform Each action has a “type” field and action-specific “data” | See next two rows |
”type” | string | required | Specifies type of action. This is DIFFERENT to the “type” used in signature headers |
|
“data” | object | required | Contains signed request payloads of individual actions. Fields are identical to the corresponding standalone endpoints: create limit order, create market order, cancel order, edit order, create position TP/SL, and cancel stop order. | See code block below. Messages and corresponding fields are identical to create and cancel requests. |
Response
- Status 200: Batch operations processed successfully
- Status 400: Bad request
- Status 500: Internal server error
Notes on Batch Ordering
Speed Bump (Latency Protection)
Batch orders are subject to a conditional ~200ms delay to protect liquidity providers from adverse selection:Speed bump is applied if the batch contains:
- Market orders (CreateMarket)
- Limit orders with TIF = GTC or IOC
- Add Liquidity Only orders (TIF = ALO)
- Top of Book orders (TIF = TOB)
- Cancel operations
- TP/SL operations
Signature Requirements
- Each action in the batch must be individually signed
- All signatures must be valid for the batch to process
Execution Behavior and Limits
- Maximum 10 actions per batch request
- Actions are executed atomically in the order provided
- If one action fails, subsequent actions are still attempted