The SDK is a thin typed layer over two wire protocols:
- ConnectRPC over HTTP for unary requests (binary Protobuf by default)
- Centrifugo over WebSocket for realtime (binary Protobuf client protocol and payloads)
Config / credentials API URL, WS URL, Ed25519 key material, Account ID
|
`AsyncPolyester` / `Polyester` wires transports, catalogs, and service accessors
├── Connect transport public + authenticated unary calls
├── Realtime client shared WebSocket multiplexer
├── Catalogs spot + Zipper reference data / scales
├── Services orders, market_data, balances, ...
└── chain on-chain Funding helpers (not ConnectRPC)Python ships async (AsyncPolyester) and sync (Polyester) clients with the same service tree. Prefer async for bots with streams.
Aliases: client.candles → market_data, client.trading_withdraws → withdraw. Account resolve is out of scope for API-key SDKs.
Services are accessed as attributes/fields on the client (client.orders, client.market_data, …). Catalog hydration usually starts on client create;
wait before decimal writes that depend on scales.
Related: Environments, Client configuration, Realtime.
Related Topics
Environments Default testnet endpoints and how to point the client at another deployment. Authentication model Ed25519 API-key request signing for ConnectRPC and private realtime channels. Catalog & precision Spot/Zipper catalogs, decimal strings, and scaled-integer inputs. Requests & idempotency How Python SDK calls are shaped, cancelled, retried, and reconciled with client order ids and request ids. Limitations & non-features What API-key SDKs intentionally omit, and where to go instead.