Request Construction
A signed request can succeed while the application handles its result incorrectly. A timeout can occur after an order was accepted. A reconnect can restore a subscription while leaving a hole in the recorded trades. Moving transport code into an SDK does not resolve those application decisions.
The Siebly SDKs provide exchange-specific clients. A Bybit client accepts Bybit categories and request fields; a Binance client exposes its own product-specific methods. Their interfaces remain different because the underlying APIs are different.
The client serializes parameters, signs private requests, and sends the headers expected by the endpoint. TypeScript declarations describe supported inputs and responses. Public calls can be made without adding credentials:
A typed public request
import { RestClientV5 } from 'bybit-api';
const client = new RestClientV5();
const response = await client.getTickers({
category: 'linear',
symbol: 'BTCUSDT',
});
if (response.retCode !== 0) throw new Error(response.retMsg);
console.log(response.result.list);
The category is checked during TypeScript development. The returned JSON still crosses a runtime boundary. An external payload is not made trustworthy merely because a declaration describes its expected shape. Validate the fields the application consumes.
Application Responsibilities
| Concern | Client behaviour | Application work |
|---|---|---|
| Request signing | Applies the endpoint's authentication scheme. | Select the correct credentials, environment, and permissions. |
| REST results | Exposes methods and exchange responses. | Check business acceptance and preserve useful error details. |
| Request volume | Some clients expose rate-limit feedback. | Share a request budget across the processes counted together. |
| Pagination | Exposes the endpoint's cursor and parameters. | Iterate, detect stalled cursors, and save progress with the records. |
| WebSocket lifecycle | Handles supported heartbeats, reconnects, and subscriptions. | Repair missed history and application state. |
| Order submission | Sends the requested command. | Persist identity, handle unknown outcomes, and decide whether another attempt is allowed. |
These clients do not automatically throttle REST traffic or provide a general failed-order retry policy. A shared request budget and order-state handling belong above the client.
Keep a Small Connector
A connector can translate the native response into the fields one application needs while retaining the original identifiers. It should also expose unsupported operations rather than silently changing their meaning. A venue without the required order type cannot be made equivalent by renaming a field.
Integration tests should exercise that boundary. Mocking a method can test application decisions, but it cannot prove that real credentials, routing, signing, or event subscriptions work.
Raw requests remain reasonable for a small experiment or an unsupported endpoint. The cost changes when several services each maintain their own signer and connection lifecycle. An SDK moves that repeated protocol code into a maintained dependency; the connector keeps application behaviour reviewable.
Related articles
Continue from here