CCXT vs the Mudrex API and the official Mudrex Python SDK

Mudrex is an India-based venue whose futures API lives at https://trade.mudrex.com/fapi/v1. Its own documentation describes an X-Authentication header carrying your API secret, a public market-data surface that needs no authentication, and live kline, mark-kline and ticker streams over WebSocket.

Mudrex publishes one client library: mudrex-python-sdk, on PyPI as mudrex-sdk. Its README describes it as the "Official Python SDK for the Mudrex HTTP APIs" and says it "currently supports only the Trading API (futures orders, positions, leverage, wallet, etc.) via the TradeClient".

CCXT speaks the same API behind method names shared with 103 other venues. The question that decides between them: is Python-only, trading-only coverage enough, or do you want market data, streaming and other languages too?

TL;DR

• Pick mudrex-sdk if you are in Python, Mudrex is your only venue, and you want method and field names that match Mudrex's own reference exactly — place_order(..., order_type="LONG", trigger_type="MARKET") is Mudrex's model, not a translation of it.
• Pick CCXT if you want market data as well as trading, WebSocket candles and tickers, a rate limiter that is on by default, and the same code in TypeScript, JavaScript, Python, PHP, C#/.NET, Go or Java.
• Rate limiting is the sharpest difference. The SDK's README states: "This SDK does not throttle requests — it fires them immediately… You are responsible for pacing your requests." CCXT's throttler is on by default with per-endpoint weights.

At a glance

_{Figures verified September 2026 against CCXT v4.5.77, the mudrex-python-sdk README, the mudrex-sdk PyPI record (v0.1.1, published April 2026) and Mudrex's own API documentation.}

The same job, written both ways

Fetch a ticker

import ccxt

exchange = ccxt.mudrex()
ticker = exchange.fetch_ticker('BTC/USDT:USDT')
print(ticker['last'], ticker['baseVolume'])

There is no ticker method in the SDK. get_future() returns the contract record, and list_futures() enumerates contracts — the SDK's own API reference lists no market-data call beyond those. CCXT returns a unified ticker structure with the same keys, types and units you get from Binance or Bybit, plus fetch_ohlcv and fetch_mark_ohlcv for candles.

Place a limit order

import ccxt

exchange = ccxt.mudrex({'secret': '...'})
order = exchange.create_order('BTC/USDT:USDT', 'limit', 'buy', 0.001, 60000)
print(order['id'], order['status'])

The two models are genuinely different, not just differently spelled. Mudrex's order_type is direction (LONG / SHORT) and trigger_type is execution style (MARKET / LIMIT). CCXT maps that onto the unified side / type pair that every other exchange uses, so the same strategy code places an order on Mudrex and on Bybit.

Two other footguns the SDK documents and CCXT removes. The README warns that numeric parameters accept str, int or float and that "The SDK does not convert types… pass strings" to avoid float serialisation problems — CCXT's Precise string arithmetic and amount_to_precision handle that. And the README explains that single-object responses carry order_id while list responses carry id; CCXT normalises both to order['id'].

Stream candles

import ccxt.pro
import asyncio

async def main():
    exchange = ccxt.pro.mudrex()
    while True:
        candles = await exchange.watch_ohlcv('BTC/USDT:USDT', '1m')
        print(candles[-1])

asyncio.run(main())

CCXT implements three streaming methods for mudrex — watchOHLCV, watchTicker and watchTickers — against wss://trade.mudrex.com/fapi/v1/price/ws/linear, with connection pooling, ping/pong keep-alive, automatic reconnect and resubscribe, and a bounded candle cache. watch_ohlcv returns the same array shape as fetch_ohlcv, so swapping a polling loop for a stream leaves the downstream code untouched.

There are no private streams for mudrex in CCXT — orders, positions and balances are REST-only on this venue.

Where the differences actually bite

Rate limits you do not have to model

The SDK's README is unusually direct about this. It lists Mudrex's limits — 2 requests/second, 50/minute, 1000/hour, 10000/day — and then says the SDK "does not retry or throttle", advises you to "add a small delay between calls (e.g. time.sleep(0.5))", and tells you to catch the 429 and back off yourself.

CCXT ships a token-bucket throttler that is on by default (enableRateLimit = true), with per-endpoint weights encoded in the exchange definition — wallet and funds reads cost five times a contract lookup, order placement and cancellation cost double. If your tier is tighter than CCXT's default pace, raise the interval once and every call obeys it:

exchange = ccxt.mudrex({'secret': '...'})
exchange.rateLimit = 500          # ms between requests
exchange.enableRateLimit = True   # already the default

One error hierarchy

CCXT maps Mudrex's error responses onto a typed exception tree — InsufficientFunds, InvalidOrder, OrderNotFound, RateLimitExceeded, AuthenticationError, NetworkError, ExchangeNotAvailable and 34 more, all descending from BaseError. The SDK raises MudrexAPIError (with code, message, response) and MudrexRequestError, so classifying "out of funds" versus "bad price" versus "rate limited" is string or code matching you write and maintain.

Precision, rounding and string math

load_markets() pulls Mudrex's tick and step sizes, and CCXT exposes them through amount_to_precision, price_to_precision and cost_to_precision, backed by the Precise string-arithmetic class:

amount = exchange.amount_to_precision('BTC/USDT:USDT', 0.0012345678)
price = exchange.price_to_precision('BTC/USDT:USDT', 61234.56789)

The SDK explicitly leaves this to you — its troubleshooting section walks through the "Order value less than minimum required value" error and tells you to read min_order_value from get_future(symbol) yourself.

Seven languages, one API

CCXT is written once in TypeScript and transpiled to JavaScript, Python, PHP, C#/.NET, Go and Java, with identical method names and return structures in every one. mudrex-sdk is Python only.

import ccxt
exchange = ccxt.mudrex()
ticker = exchange.fetch_ticker('BTC/USDT:USDT')

Nothing is hidden — the implicit API

Alongside the 30 unified capabilities, all 26 endpoints in the API definition are generated as callable implicit methods, with authentication, rate-limit accounting and error mapping applied:

# any raw Mudrex endpoint, camelCased from its path
response = exchange.private_get_futures_positions_position_id_liq_price({
    'position_id': '...'})

Browse them on the mudrex implicit API page.

Portability

CCXT's mudrex is the same object shape as its binance, bybit and okx objects, so adding a second venue does not mean a second data model:

for exchange_id in ['mudrex', 'binance', 'bybit']:
    exchange = getattr(ccxt, exchange_id)()
    print(exchange_id, exchange.fetch_ticker('BTC/USDT:USDT')['last'])

What mudrex-sdk does better

An honest list, because these are real:

• It is first-party. Mudrex writes the API and the SDK. New Mudrex endpoints and parameter changes land there first, and its README is maintained against the live API rather than reverse-engineered.
• Field names match the Mudrex docs exactly. order_type="LONG", trigger_type="MARKET", position_id, min_order_value — while you are debugging with the vendor reference open, that is one less hop than CCXT's deliberate abstraction.
• Typed response objects with attribute access. resp.order_id, order.id, position.id — the SDK returns model objects rather than dictionaries, and the README documents exactly which id lives where.
• Mudrex-specific plumbing is surfaced directly. Wallet-to-futures transfers, the INR transfer endpoint, reverse_position, close_position_partial, place_risk_order / amend_risk_order and get_liquidation_price are first-class methods with docstrings.
• A far smaller dependency. If all you do is place futures orders on Mudrex from Python, one small requests-based package is a smaller install and a smaller surface than a library covering 104 exchanges.

If Mudrex is your only venue, you are writing Python, and you are happy to pace requests and parse market data yourself, the official SDK is a defensible choice.

Migrating from mudrex-sdk to CCXT

Start with Install, then the Manual, then the mudrex unified API reference.

FAQ

Does the official Mudrex SDK support market data? Not beyond contract metadata. The README says it "currently supports only the Trading API (futures orders, positions, leverage, wallet, etc.)", and its API reference lists list_futures and get_future but no ticker, order book or candle method. CCXT implements fetch_ticker, fetch_tickers, fetch_ohlcv and fetch_mark_ohlcv for mudrex.

Does CCXT support Mudrex WebSockets? Partly. CCXT implements three watch* methods — watchOHLCV, watchTicker and watchTickers — against Mudrex's public price stream. There are no private (order, position, balance) streams for this venue in CCXT, and none in the official SDK either.

Does either library handle Mudrex's rate limits for me? CCXT does: the throttler is on by default with per-endpoint weights. mudrex-sdk does not — its README states it fires requests immediately and that pacing and back-off are your responsibility.

What credentials does CCXT need for Mudrex? Only the secret, sent as the X-Authentication header: ccxt.mudrex({'secret': '...'}). Mudrex does not use a separate API key or an HMAC signature.

Does Mudrex have a testnet? No. Mudrex publishes no sandbox environment, so set_sandbox_mode(True) has nothing to point at. Test against CCXT's offline static fixtures and small live orders.

Is CCXT free? Yes. MIT-licensed, including the WebSocket support.

Next steps

• Install CCXT in your language
• Manual — the unified API, structures and conventions
• mudrex unified API reference
• mudrex implicit API — every raw endpoint
• CCXT Pro manual — WebSocket methods
• More comparisons