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
|
`polyester::Client` 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)Rust has no candles / trading_withdraws aliases. Use market_data and 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.
High-level service methods own authentication and request signing. The generated bindings under polyester::connect are deliberately low level and unsigned; use them only when you are prepared
to implement the full wire contract yourself.
Related
Related Topics
Environments Default devnet 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 Rust call conventions, cancellation, and idempotency keys for orders and triggers. Limitations & non-features What API-key SDKs intentionally omit, and where to go instead.