Changelogs

Release Summary

---

Changelog - v1.0.12

Release Date: October 1, 2026

Breaking Changes: Yes — Square off and Partial close responses.

Deprecations: No

API changes live since September 30, 2026, on the existing /fapi/v1 paths. Each change is labelled Breaking or Non-breaking.

Added

position_id on order responses — Non-breaking

• Endpoints: POST /fapi/v2/futures/order, POST /fapi/v1/futures/{asset_id}/order, POST /fapi/v1/futures/positions/{position_id}/reverse, GET /fapi/v1/futures/orders/{order_id}, GET /fapi/v1/futures/orders/detail, GET /fapi/v1/futures/orders, GET /fapi/v1/futures/orders/history, GET /fapi/v1/futures/orders/{order_id}/execution-report
• position_id: UUID of the position the order belongs to. On order reads it equals future_position_uuid (unchanged).
• Place returns position_id before the order fills. The position is listed in Open Positions once it is OPEN.
• Docs: Order and position IDs

position_id on Open Positions — Non-breaking

• Endpoint: GET /fapi/v1/futures/positions
• position_id: same value as id (unchanged).
• Docs: Open Positions

position_id and order_id on Position history — Non-breaking

• Endpoint: GET /fapi/v1/futures/positions/history
• position_id: position UUID. order_id: UUID of the order that closed that quantity. id remains the history row UUID.
• Returned on all rows, including rows created before this release.
• Docs: Position history

previous_funding_interval on assets — Non-breaking

• Endpoints: GET /fapi/v1/futures, GET /fapi/v1/futures/{asset_id}
• previous_funding_interval: previous funding time, Unix epoch seconds. funding_interval (unchanged) is the next funding time.
• Funding interval = funding_interval - previous_funding_interval.
• Docs: Funding interval

Changed

Square off response — Breaking

• Endpoint: POST /fapi/v1/futures/positions/{position_id}/close
• position_id now contains the position UUID. Previously it contained the close order UUID.
• New field order_id contains the close order UUID.
• Docs: Square off

Partial close response — Breaking

• Endpoint: POST /fapi/v1/futures/positions/{position_id}/close/partial
• data is now an object with order_id, position_id, and quantity. Previously it was the boolean true.
• Docs: Partial Close

Fixed

Docs corrections

• Position history: id is the history row UUID, not the position UUID.
• Asset by id: removed trading_fee_perc, which is not returned. Example values for max_funding_rate / min_funding_rate updated.
• Order responses: actual_amount is the order value (quantity × price) in trade_currency.
• Liquidation price: trade_currency=INR is required with ext_margin for INR positions.
• Add/reduce margin: error texts margin is required, margin less than required margin and margin cannot be greater than max margin documented.
• Position history and Order history: offset time cursor (epoch ms) documented for paging. page and per_page are not supported.
• Authentication & Rate Limits: Retry-After on HTTP 429 and fixed clock-window resets documented.

Known Issues

actual_amount on partially filled orders

• When an order is partially filled and the remainder is cancelled, actual_amount returns price × ordered quantity instead of the filled value, and status can remain PARTIAL_FILLED. Fully filled orders are not affected; fees are charged on the filled quantity only. Workaround: USDT filled_quantity × filled_price; INR filled_quantity × filled_price × hedge_rate.
• Docs: Order by id, Order history, Execution report, Client order ID, Open orders

Migration Notes

• Square off: read the close order UUID from data.order_id. data.position_id is the position UUID.

  Before:

  JSON

  { "success": true, "data": { "position_id": "<close order UUID>", "status": "CREATED", "message": "OK" } }

  After:

  JSON

  { "success": true, "data": { "order_id": "<close order UUID>", "position_id": "<position UUID>", "status": "CREATED", "message": "OK" } }

• Partial close: treat data as an object. Replace checks such as data === true with success === true, and read data.order_id.

  Before:

  JSON

  { "success": true, "data": true }

  After:

  JSON

  { "success": true, "data": { "order_id": "<partial close order UUID>", "position_id": "<position UUID>", "quantity": "4" } }

• All other changes add fields. No action is needed.

---

Changelog - v1.0.11

Release Date: September 23, 2026

Breaking Changes: No

Deprecations: No

Added

Client order ID

• Optional client_order_id on POST /fapi/v2/futures/order (returned on the place response when set).
• Format: letters, digits, hyphen (-), underscore (_); max 64 characters; case-sensitive. Invalid values return 400 with "Invalid order identifier." (no order created).
• Optional client_order_id query on DELETE /fapi/v1/futures/orders (path cancel by UUID unchanged).
• Optional stoploss_client_order_id / takeprofit_client_order_id on POST and PATCH /fapi/v1/futures/positions/{position_id}/riskorder.
• Optional client_order_id on POST /fapi/v1/futures/positions/{position_id}/close/partial.
• Nullable client_order_id on FutureOrder response objects (open orders, order history, get-by-id, detail, place response, execution report when present).
• Docs: Client order ID

Get order detail

• Endpoint: GET /fapi/v1/futures/orders/detail?order_id=<uuid> or ?client_order_id=<string>
• Response matches get order by id. Preferred when you may have either id.
• Docs: Client order ID

Fixed

Get order identity parity

• GET /fapi/v1/futures/orders/{order_id} returns symbol, asset_uuid, and future_position_uuid consistent with Open orders / Order history for the same order id (including FILLED).
• Docs: Order by id

Changelog - v1.0.10

Release Date: September 21, 2026

Breaking Changes: No — the v1 order endpoint is unchanged and still supported.

Deprecations: No

Order placement is the first operation with its own path version. Everything else in the API stays on /fapi/v1.

Added

Create order (v2)

• Endpoint: POST /fapi/v2/futures/order?id=<asset_uuid> or POST /fapi/v2/futures/order?symbol=<symbol>
• The asset moves from a path segment to a query parameter; ?is_symbol is no longer used.
• Body: trigger_type, order_type, quantity (required); trade_currency, order_price, is_stoploss, stoploss_price, is_takeprofit, takeprofit_price, reduce_only (optional / conditional).
• Returns 202 Accepted with order_id, price, quantity, leverage, status, message.
• Adds 423 — action not allowed: another user action in progress — when a concurrent order or liquidation holds the lock for the same user and symbol.

Execution report

• Endpoint: GET /fapi/v1/futures/orders/{order_id}/execution-report
• Per-fill breakdown for an order: maker/taker (is_maker), fill price, quantity, trading fee, and transaction id (trxn_id).
• executions[].filled_time is an ISO-8601 string (e.g. 2026-09-07T11:09:35.415Z), not an integer epoch.

Fee by id

• Endpoint: GET /fapi/v1/futures/fee/{fee_id}
• Single fee record by fee UUID (from fee history). Includes role (MAKER / TAKER) and fills[] (fee_rate, is_maker) when returned.
• Lookup is by fee id only — not by symbol.

Changed

Maker / taker fees

• Trading fees move from a flat fee model to maker/taker.
• Fee history and fee-by-id include role (MAKER / TAKER) and fills[] (fee_rate, is_maker) when returned.
• Execution report includes is_maker on each fill.

Reverse position response

• Endpoint: POST /fapi/v1/futures/positions/{position_id}/reverse
• Response data no longer includes amount. Fields returned: leverage, quantity, price, order_id, status, message.

Changed — v2 behaviour only

• leverage is no longer accepted in the order body. v2 uses the leverage saved for the asset; set it with POST /futures/{asset_id}/leverage first, or the call returns 400 leverage not found.
• actual_amount / desired_amount are no longer accepted. The amount is always quantity × price.
• Stop-loss is no longer validated against the liquidation price. Callers are responsible for that check.
• Available balance no longer includes unsettled PnL, so margin checks can be stricter than in v1.

Migration Notes

• No action needed to stay on v1 — POST /fapi/v1/futures/{asset_id}/order is unchanged.
• To move to v2: send the asset as ?id= or ?symbol=, drop leverage from the body and set it separately, drop actual_amount / desired_amount, and handle 423 with a short retry.

---

Changelog - v1.0.9

Release Date: June 26, 2026

Breaking Changes: No

Deprecations: No

Public, read-only market-data surface — independent of the authenticated trading API and of margin currency. No API key or authentication header is required.

Added

1. Historical klines (REST)

• Endpoint: GET /fapi/v1/price/kline
• Returns up to 1440 candles per asset; each candle is a 6-element array [open_time, open, high, low, close, volume]. Invalid/empty symbols are omitted.

2. Historical mark-price klines (REST)

• Endpoint: GET /fapi/v1/price/mark-kline
• Same shape as klines but OHLC only — each candle is a 5-element array.

3. Live streaming (WebSocket)

• Endpoint: wss://trade.mudrex.com/fapi/v1/price/ws/linear
• Streams: kline@1s / kline@1m, markKline@1s / markKline@1m, and ticker@1s / ticker@5s.
• Methods: SUBSCRIBE, UNSUBSCRIBE, LIST_SUBSCRIPTIONS. Keepalive: server closes after 40s idle; recommended PING every 20s. Subscriptions are per-connection and not persisted.

---

Changelog - v1.0.8

Release Date: June 16, 2026

Breaking Changes: No

Deprecations: No

Backward compatibility. Existing USDT-only requests behave exactly as before. When trade_currency is omitted, requests return USDT data. Responses gain only additive fields; no field is renamed or removed. No client migration is required.

Added

1. Currency parameter

• Add trade_currency (USDT | INR) to operate in a given currency.
  • Query parameter on GET; body field on POST / PATCH / DELETE.
  • Omitted defaults to USDT.
  • Unsupported values return 400 Invalid trade currency.
• The spot balance read (GET /wallet/funds) uses the currency query parameter (USDT | INR).

2. INR wallet reads

• GET /wallet/funds?currency=INR — INR spot wallet balance.
• GET /futures/funds?trade_currency=INR — INR futures wallet balance (balance, locked_amount, first_time_user).

3. INR transfers

• Endpoint: POST /futures/transfers/inr
• Body: amount, from_wallet_type, to_wallet_type (SPOT / FUTURES).
• Response: 202 Accepted with { "id": "<transaction_id>" }.
• The USDT transfer path POST /wallet/futures/transfer does not accept INR.

4. Futures transactions

• GET /futures/transactions?trade_currency=INR with type (DEPOSIT / WITHDRAW), status, sort_by, sort_order, limit filters.

5. Per-(asset, currency) leverage

• GET / POST /futures/{asset_id}/leverage accept trade_currency; INR and USDT leverage are independent.
• Response includes margin_type, leverage, collateral_currency_id.
• Leverage never set for an (asset, currency) returns 404 leverage not found.

6. INR-margin order & position lifecycle

• Order create/amend/cancel, open orders, order history, order-by-id.
• Open positions, position history, liquidation price, add/reduce margin, set/edit SL/TP, partial close, reverse, square off.
• Fee history.
• All accept and/or return INR per the currency parameter.

7. Additive response fields

• trade_currency tag on orders, positions, and fee records.
• FX rate: hedge_rate (orders); entry_hedge_rate / exit_hedge_rate (positions / history).
• gst_amount on INR fee records.
• collateral_currency_id on leverage responses.

Changed

• Currency-scoped list endpoints — GET /futures/orders, /futures/orders/history, /futures/positions, /futures/positions/history, /futures/fee/history, /futures/transactions return one currency per call, default to USDT, never mix currencies, and tag each item with trade_currency.

Migration Notes

• No changes required. Omitting trade_currency preserves existing USDT behaviour.

---

Changelog - v1.0.7

Release Date: June 2, 2026

Breaking Changes: No

Deprecations: No

Changed

Fee History API Response Enhancement

Enhanced Fee History API response with additional fee-level metadata, including order details and GST information.

• Endpoint: GET /fapi/v1/futures/fee/history
• Added Fields:
  • id – Unique identifier for a fee
  • order_type – Type of order (LONG, SHORT, STOPLOSS, TAKEPROFIT)
  • trigger_type – Trigger type of the order (MARKET, LIMIT)
  • gst_amount – GST charged for the order
• Notes: order_type and trigger_type are applicable only when fee_type is TRANSACTION or REBATE.

Migration Notes

• No changes required. Existing integrations continue to work without modification.

---

Changelog - v1.0.6

Release Date: May 12, 2026

Breaking Changes: No · Deprecations: No

Changed

1. Default API Rate Limits Updated

Enhanced default API rate limits across all endpoints to support higher throughput and trading activity.

2. Wallet Endpoint Rate Limits

Wallet endpoints (POST /fapi/v1/wallet/funds, POST /fapi/v1/wallet/futures/transfer) continue to use separate rate limits.

Migration Notes

• No changes required. Existing integrations continue to work without modification.

---

Changelog - v1.0.5

Release Date: April 21, 2026

Breaking Changes: No · Deprecations: No

Added

• Mudrex Python SDK initial release; TradeClient for Futures API interaction; API secret–based authentication (direct + environment variable support).
• Core SDK methods: place order, set leverage, get leverage, fetch positions, cancel order.
• Error handling: MudrexAPIError, MudrexRequestError.

---

Changelog - v1.0.4

Release Date: April 15, 2026

Breaking Changes: No · Deprecations: No

Changed

1. Rate Limits Update for Trading Endpoints

Enhanced rate limits for core trading endpoints to support higher throughput.

• Endpoints: POST /fapi/v1/futures/:asset_id/order, DELETE /fapi/v1/futures/orders/:order_id, POST /fapi/v1/futures/positions/:position_id/add-margin, POST & PATCH /fapi/v1/futures/positions/:position_id/riskorder, POST /fapi/v1/futures/positions/:position_id/reverse, POST /fapi/v1/futures/positions/:position_id/close/partial, POST /fapi/v1/futures/positions/:position_id/close, GET & POST /fapi/v1/futures/:asset_id/leverage.

• Unchanged: all other endpoints continue to use existing limits (Second 2, Minute 50, Hour 1000, Day 10000).

2. Removed PnL data from the response

• Endpoint: GET /fapi/v1/futures/positions
• Removed stale PnL data from the response to avoid inaccurate position reporting.

Migration Notes

• No changes required. Existing integrations continue to work without modification.

---

Changelog - v1.0.3

Release Date: January 22, 2025

Breaking Changes: No · Deprecations: No

Added

• MCP Server Integration Guide.

---

Changelog - v1.0.2

Release Date: December 8, 2025

Breaking Changes: No · Deprecations: No

Changed

• Status code and message for POST /fapi/v1/wallet/futures/transfer: 200 OK → 202 Accepted; message internal_wallet_fund_transfer_request successful → internal wallet fund transfer request accepted.

---

Changelog - v1.0.1

Release Date: December 5, 2025

Breaking Changes: No · Deprecations: No

Added

1. Add / Reduce Margin API — POST /fapi/v1/futures/positions/:positionID/add-margin (margin float; positive adds, negative reduces). Returns updated initial_margin and liquidation_price.
2. Estimated Liquidation Price API — GET /fapi/v1/futures/positions/:positionID/liq-price?ext_margin=2.1 (ext_margin optional hypothetical margin change; if omitted or 0, returns current liquidation price).
3. Symbol-First API Trading Support — ?is_symbol (presence-based) on GET /fapi/v1/futures/:id, GET/POST /fapi/v1/futures/:id/leverage, POST /fapi/v1/futures/:id/order. Asset-ID flows remain functional.

Changed

• Get Assets / Asset Info — removed contract_multiplier, price_scale; fixed min_funding_rate / max_funding_rate.
• Place Order — success status 200 OK → 202 Accepted.
• Order History — removed desired_amount, liquidation_price.
• Open Positions — removed closed_price.
• Position History — removed unrealised_pnl.
• Place / Amend Risk Order — user_id, order_id, exchange_order_id, id now ignored; improved errors (404 invalid position, 400 not OPEN).
• Reverse Position — success status 200 OK → 202 Accepted.

Migration Notes

• Update clients to accept 202 Accepted for order placement and reverse position operations. Stop relying on removed fields. Existing asset-ID-based flows continue to work.

---

Changelog - v1.0.0

Release Date: Nov 5, 2025

Initial API trading support — Wallet (GET /wallet/funds, POST /wallet/futures/transfer), Futures (GET /futures/funds), Assets (GET /futures, GET /futures/:asset_id), Leverage (GET/POST /futures/:asset_id/leverage), Orders (place / list / history / detail / amend / cancel), Positions (list / history / riskorder / close / partial / reverse), Fees (GET /fapi/v1/futures/fee/history).