CCXT vs the Hibachi API

Hibachi is a perpetuals venue with a public market-data host (data-api.hibachi.xyz) and a signed trading host (api.hibachi.xyz). Orders are signed with a private key rather than only authenticated with a secret, which puts it in the same family as other self-custodial perpetuals venues.

Hibachi publishes an official Python SDK, hibachi-xyz, and CCXT implements the venue as ccxt.hibachi. The choice comes down to two things, and one of them cuts against CCXT: which language you write in, and whether you need WebSocket streaming today.

TL;DR

• Pick Hibachi's own SDK if you work in Python 3.13 or later and need WebSocket streaming — Hibachi's SDK has it and CCXT's Hibachi integration does not.
• Pick CCXT if you write in TypeScript, Go, C#, PHP, Java or an older Python, or if Hibachi is one venue among several and you want one interface across all of them.
• Choosing CCXT does not hide Hibachi's API. All 28 Hibachi endpoints are generated as implicit methods, signed and rate-limited like any unified call.

At a glance

_{Figures verified September 2026 against CCXT v4.5.77, the hibachi-xyz/hibachi_sdk repository and the hibachi-xyz PyPI listing.}

The same job, written both ways

Fetch market data

import ccxt

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

The SDK splits market data across get_exchange_info() for contract metadata, get_prices() for price and funding information, get_stats() for 24-hour high, low and volume, and get_orderbook(symbol, depth, granularity) for depth. CCXT folds the first three into one unified ticker structure, keyed by the unified symbol: Hibachi's own instrument id is BTC/USDT-P, CCXT's is 'BTC/USDT:USDT' — the same string you pass to ccxt.binance, ccxt.bybit or ccxt.hyperliquid for the equivalent contract.

Place a limit order

import ccxt

exchange = ccxt.hibachi({
    'apiKey': '...',
    'accountId': 123,
    'privateKey': '...',
})
order = exchange.create_order('BTC/USDT:USDT', 'limit', 'buy', 0.001, 50000)
print(order['id'], order['status'])

Both sides need the same three credentials — an API key, a numeric account id and a private key — because Hibachi orders are cryptographically signed, not just authenticated. Both sides do the signing for you. What differs is the return: CCXT gives you a unified order structure with id, status, filled, remaining, average and the rest, in the same shape every other exchange returns.

Where the differences actually bite

Seven languages, one API

This is the main reason to choose CCXT here. hibachi-xyz is Python-only, and the published package declares Python 3.13 or later — so even a Python 3.11 service cannot install it. CCXT is written once in TypeScript and transpiled to JavaScript, Python, PHP, C#/.NET, Go and Java with identical method names and return structures.

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

Portability across venue types

Hibachi is a signed-order, self-custodial perpetuals venue. That normally means a bespoke integration: key handling, a nonce scheme, an instrument naming convention of its own. In CCXT it is the same interface as a centralised exchange, so quoting Hibachi against another venue does not need a translation layer:

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

Signing you do not implement

Hibachi requires three credentials — apiKey, accountId and privateKey — and signs order payloads with an ECDSA signature over a hashed message (falling back to HMAC-SHA256 for shorter keys). CCXT implements that internally, using its own audited crypto helpers rather than an external dependency, so key material stays in your process and the signature format tracks Hibachi's changes as a library update rather than a code change on your side.

Rate limits, precision and errors

• Rate limiting. CCXT's token-bucket throttler is on by default (enableRateLimit = true, rateLimit = 100 ms). You call methods in a loop; the library paces them.
• Precision. Hibachi uses tick-size precision and rejects orders that violate tick size, lot size or minimum notional. amount_to_precision, price_to_precision and cost_to_precision are backed by the Precise string-arithmetic class, so quantities do not drift through float rounding.
• Errors. CCXT maps Hibachi's failures onto a typed exception tree — InsufficientFunds, InvalidOrder, OrderNotFound, AuthenticationError, NetworkError and 36 more, all under BaseError — so except ccxt.InsufficientFunds keeps working on the next venue.

No sandbox

CCXT's Hibachi definition has no test URLs, so exchange.set_sandbox_mode(True) raises NotSupported. Plan to validate against a small live account, and use CCXT's static request and response fixtures for regression testing rather than expecting a paper-trading environment.

Nothing is hidden — the implicit API

Alongside the 33 unified capabilities, all 28 endpoints in CCXT's Hibachi api block are generated as callable implicit methods, camelCased from their paths:

funding = exchange.public_get_market_data_funding_rates()
oi = exchange.public_get_market_data_open_interest()
inventory = exchange.public_get_market_inventory()

Signing, rate-limit accounting and error mapping still apply. Browse them on the Hibachi implicit API page.

What hibachi-xyz does better

An honest list, and the first item is the important one:

• It has WebSockets and CCXT does not. The SDK ships HibachiWSMarketClient and matching trade and account clients, with subscriptions for mark price, spot price, funding rate, trades, candlesticks, order book and ask/bid prices, plus WebSocket-based order management. CCXT has no watch* methods for Hibachi — you poll fetch_order_book, fetch_trades and fetch_open_orders instead. If you need low-latency streaming on Hibachi today, the vendor SDK is the one that provides it.
• Typed, Hibachi-shaped models. The SDK returns typed objects for Hibachi's own payloads, with its own error types. CCXT returns typed unified structures — better for portability, less literal about Hibachi's wire format.
• Hibachi-specific features land there first. A new endpoint or order flag appears in the vendor SDK on Hibachi's schedule. CCXT's implicit API closes most of that gap immediately, but a unified wrapper may lag.
• A smaller dependency if Hibachi is all you need. If your entire system talks to Hibachi and nothing else, in Python 3.13, hibachi-xyz is a much smaller install than all of CCXT.

If Hibachi is your only venue, you are on Python 3.13 or later, and you need streaming, the official SDK is the better choice today.

Migrating from hibachi-xyz to CCXT

FAQ

Does CCXT support Hibachi WebSockets? No. Hibachi has no watch* methods in CCXT, so streaming is not available through ccxt.pro.hibachi. Use the fetch* methods and poll, or use Hibachi's own Python SDK, which does expose market, trade and account WebSocket APIs. CCXT supports WebSockets on 76 of its 104 exchanges; Hibachi is not one of them today.

What credentials does CCXT need for Hibachi? Three: apiKey, accountId and privateKey. Hibachi orders are signed, so the private key is required for any trading call. CCXT performs the signing internally.

Does Hibachi have a testnet I can use through CCXT? No. CCXT's Hibachi definition has no test URLs, so set_sandbox_mode(True) raises NotSupported.

Does CCXT support Hibachi spot markets? Hibachi is a perpetuals venue — has.spot is false and has.swap is true. All 33 unified capabilities apply to perpetual contracts.

Can I still call Hibachi-specific endpoints through CCXT? Yes — all 28 endpoints in CCXT's Hibachi definition are generated as implicit methods, with signing, rate limiting and error mapping applied.

Is CCXT free? Yes. MIT-licensed.

Next steps

• Install CCXT in your language
• Manual — the unified API, structures and conventions
• hibachi unified API reference
• hibachi implicit API — every raw endpoint
• More comparisons