Order creation

The following operations not only require user authorization but often also require a wallet signature:

1. Withdrawal from trading account

2. Creation of limit, market, and stop-limit orders

3. Replacement of limit and stop-limit orders

4. Cancellation of limit and stop-limit orders

5. Position closure

6. Leverage change for positions

7. Creation, modification, and cancellation of TpSl

Withdrawal

This operation is executed via the POST /api/transfer/pf/withdraw REST API method by specifying the currency, withdrawal amount, recipient wallet address, and a signature.

Signature schema

Important: Before signing, all float values must be normalized to integers according to the documentation.

Important: The withdrawal request is pre-validated by the exchange. If funds are available, the user's trading account is locked until the operation completes.

Only unreserved funds (not tied to positions or orders) are eligible for withdrawal.

Order Creation

These operations use the following REST API methods:

1. POST /api/v2/order/limit – create limit order (version 2)

2. POST /api/v2/order/stop-limit – create stop-limit order (version 2)

3. POST /api/v2/order/market – create market order (version 2)

4. POST /api/v2/order/mass-limit/{instrument} - batch create limit orders in batch (version 2)

All the methods require a signature. Signature schemas

timeInForce attribute for the market orders is filled as the following:

• IOC (default for market orders) - Immediate-or-cancel order. If the requested cashQuantity is unavailable in the order book, or the average price exceeds the slippage limit, the order is filled with any liquidity available on the market and a non-filled part is then cancelled.

• FOK - Fill-or-kill order is cancelled if its total cashQuantity cannot be filled immediately when the order is received.

• GTC (default for limit orders, and can't be changed via API) - Good-till-cancelled order remains working during all trading sessions till it is cancelled by a user or the order instrument is expired.

Important: Normalize all float values to integers before signing according to the documentation.

Important: Orders are pre-validated by the exchange. They may be rejected if the user lacks sufficient free margin or if limits are violated.

Important: Orders are processed asynchronously. A NEW status in the response only guarantees entry into the Order book but not execution.

Important: When batch creating limit orders, the order prefix (number or days since July 24th 2025) must be created no earlier than midnight yesterday, otherwise the request will return an error: "Invalid order ID date".

New approach to OrderId generation

With the version 2 of EVEDEX exchange API the new approach to order identifiers generation has been implemented. To prevent identifiers duplication, the new order identifier structure is: <days_since_2025-07-24>:<uuid_without_dashes>.

• days_since_2025-07-24 is the order prefix, it must be a 5-character long string containing only numbers with leading zeroes which show the number or days since July 24th 2025, e.g. 00008.

• uuid_without_dashes must be a 26-character long string containing only hexadecimal characters: numbers, upper and lower case letters from "A" to "F".

The resulting orderId must be validated against to the following regular expression: [0-9]{5}:[0-9A-Fa-f]{26}. Sample orderId: "00008:418f0157db5345688b1c910d08".

Below you can find a TypeScript implementation:

import { v4 as uuid } from "uuid";

function toShortUuid(id: string) {
  return id.replace(/-/g, "");
}

export function generateShortUuid() {
  return toShortUuid(uuid());
}

const orderIdV2Day = new Date("2025-07-24T00:00:00Z");

export function generateOrderIdV2() {
  const days = Math.floor((Date.now() - orderIdV2Day.getTime()) / (1000 * 60 * 60 * 24));
  return `${String(days).padStart(5, "0")}:${toShortUuid(uuid()).slice(0, 26)}`;
}

Order Replacement

These operations use the following REST API methods:

1. PUT /api/order/{orderId}/limit – replace limit order

2. PUT /api/order/{orderId}/stop-limit – replace stop-limit order

3. PUT /api/order/limit/{instrument} – batch replace orders

All methods require a signature. Signature schemas

Important: Normalize all float values to integers before signing according to the documentation.

Order Cancellation

These operations use the following REST API methods:

1. DELETE /api/order/{orderId} – cancel specific order

2. POST /api/order/mass-cancel – cancel all user orders for an instrument

3. POST /api/order/mass-cancel-by-id – cancel specific user orders

These methods do not require a signature.

Important: If the order is filled before the cancel request is processed, its status will not be changed to CANCELLED.

Position Closure

This operation uses the POST /api/v2/position/{instrument}/close REST API method (version 2), specifying the position volume to be closed.

Signature schema

Important: Normalize all float values to integers before signing according to the documentation.

Leverage Change

This operation uses the PUT /api/position/{instrument} REST API method, specifying the new leverage.

No signature is required.

TpSl Creation, Modification, and Cancellation

These operations use the following REST API methods:

1. POST /api/tpsl/{instrument} – create TpSl

2. POST /api/tpsl/{instrument}/id – modify TpSl

3. DELETE /api/tpsl/{instrument}/id – cancel TpSl

Signature is required for creation. Signature schema

Important: Normalize all float values to integers before signing according to the documentation.

Important: All active TpSl orders will be canceled during liquidation.