Siebly AI Skills for Trading: Developer Setup Guide

A skill can tell the agent to stay in JavaScript, read public market data, and stop before any private call. A reasonable first task is: fetch one public ticker, map the fields you care about, and handle a thrown error.

The skill does not run the bot, and it does not decide whether a trade is a good idea. Algorithmic trading is a separate topic. This guide is about getting the integration code right.

Hand-rolled clients repeat the same work: HTTP, signatures, and clock fields such as recvWindow or an OKX passphrase. A Siebly SDK already does that work, with TypeScript types for requests and responses.

What it does not do:

• It does not wait when you are near an exchange rate limit. Some responses include limit fields (Binance exchangeInfo, Gate.io getAccountRateLimit(), HTX rate-limit headers). Reading them is still your job.
• It does not retry a failed REST call. There is no shared retries option on these clients.
• WebSocket clients do reconnect on their own, and on several exchanges they resubscribe after the socket comes back. That is connection recovery. It is not “send this order again.”

For the package list, start at the Siebly SDK documentation.

Say the language, the npm package, the class, and the method. Say that the first version must not read balances, place orders, or read environment variables.

A Binance public ticker, with no keys, looks like this. The method is get24hrChangeStatistics, not getTicker.

import { MainClient } from "binance";

const client = new MainClient();

const ticker = await client.get24hrChangeStatistics({
  symbol: "BTCUSDT",
});

The same idea on other packages uses different classes, methods, and symbol strings. Copying the Binance call onto another exchange will fail.

import { RestClientV5 } from "bybit-api";

const client = new RestClientV5();
const tickers = await client.getTickers({ category: "linear" });

import { RestClient } from "okx-api";

const client = new RestClient();
const ticker = await client.getTicker({ instId: "BTC-USDT" });

import { RestClient } from "gateio-api";

const client = new RestClient();
const ticker = await client.getSpotTicker({
  currency_pair: "BTC_USDT",
});

import { SpotClient } from "kucoin-api";

const client = new SpotClient();
const ticker = await client.getTicker({ symbol: "BTC-USDT" });

import { SpotClient } from "@siebly/kraken-api";

const client = new SpotClient();
const ticker = await client.getTicker({ pair: "XBTUSD" });

import { SpotClient } from "@siebly/htx-api";

const client = new SpotClient();
const ticker = await client.getTicker({ symbol: "btcusdt" });

import { CBAdvancedTradeClient } from "coinbase-api";

const client = new CBAdvancedTradeClient({});
const product = await client.getPublicProduct({
  product_id: "BTC-USD",
});

import { RestClient } from "bitmart-api";

const client = new RestClient();
const ticker = await client.getSpotTickerV3({ symbol: "BTC_USDT" });

import { RestClientV3 } from "bitget-api";

const client = new RestClientV3();
const candles = await client.getCandles({
  symbol: "BTCUSDT",
  category: "SPOT",
  interval: "1m",
});

Bitget has two REST generations. RestClientV3 is for the Unified Trading Account. If the account is still on the older API, use RestClientV2 and its own methods, such as getSpotTicker. Do not mix the two.

Reject the output if any of these are wrong:

• Package name. Only Kraken and HTX are scoped: @siebly/kraken-api and @siebly/htx-api. The others install as binance, bybit-api, okx-api, bitget-api, gateio-api, kucoin-api, coinbase-api, and bitmart-api. There is no binance.
• Class name. Binance spot REST is MainClient. USD-M futures are USDMClient. Bybit V5 is RestClientV5. Coinbase Advanced Trade is CBAdvancedTradeClient, and that package also exports Exchange, International, Prime, App, and Commerce clients. BitMart spot is RestClient. Futures are FuturesClientV2.
• Option keys. Binance uses api_key and api_secret. Bybit uses key and secret. OKX and Bitget need apiKey, apiSecret, and apiPass. KuCoin uses apiPassphrase. BitMart uses apiMemo. Passing apiKey into MainClient or RestClientV5 does nothing useful.
• Symbol format. BTCUSDT, BTC-USDT, BTC_USDT, BTC-USD, XBTUSD, and btcusdt are all real, on different exchanges.

Then add tests for a normal payload, a missing field, and a thrown API error. Keep secrets out of the prompt. If you later use a key, store it outside the repo, and leave withdrawal permission off. The Siebly SDK documentation is the index. The exchange docs still decide what a field means.

Use the SDK when you want the signature, the timestamp, and the typed method in one place. You still need the exchange docs for required fields. An SDK method can exist and still be the wrong product. Binance submitNewOrder on USDMClient is a futures REST order. The spot WebSocket order is submitNewSpotOrder on WebsocketAPIClient. Same library, different class, different name.

OKX is the same kind of trap. REST order entry is submitOrder. The WebSocket order entry is submitNewOrder. Bybit REST is submitOrder on RestClientV5. The WebSocket trade client uses submitNewOrder.

You decide which errors are worth another attempt, how long to wait, and when to give up. The SDK will not make that decision.

WebSocket market data and WebSocket orders are different. A subscription is an event stream on WebsocketClient (or WebsocketClientV2 / WebsocketClientV3 on Bitget). An order you can await goes through WebsocketAPIClient, and only on these packages:

• binance
• bybit-api
• okx-api
• bitget-api
• gateio-api
• kucoin-api
• @siebly/kraken-api (spot only)
• @siebly/htx-api

coinbase-api has a sendWSAPIRequest method on WebsocketClient. The implementation is a stub. The comment in the client says it is not supported. Do not call it. bitmart-api has no WebsocketAPIClient. Use its REST clients for orders, and WebsocketClient for streams.

• Parsing: required fields, types, and the value you store.
• State: a repeated event, a late event, and an event for a symbol you do not track.
• Failures: HTTP error, disconnect, and a rejected order.
• Logs: enough to debug the call, and no keys or secrets.

Rate limits stay in your code. The clients in this set will not sleep for you when a weight or request cap is close.

These checks tell you the code path works. They say nothing about whether a strategy makes money.

Do not add testnet: true because another package has it. These are the flags that exist today:

A Bybit testnet client uses different option names from Binance:

import { RestClientV5 } from "bybit-api";

const client = new RestClientV5({
  testnet: true,
  key: process.env.API_KEY,
  secret: process.env.API_SECRET,
});

Binance leaves clock sync off unless you set disableTimeSync: false. Bybit leaves it off unless you set enable_time_sync: true. Same idea, opposite flag. Copy one client’s options into the other and the clock behavior will not follow.

Public examples should not contain keys. Do not paste keys into a prompt, a log, or a screenshot. When a later step needs a key, keep it in a secret store, grant the smallest permission set that works, and disable withdrawals. The Siebly SDK documentation is where you pick the package. The exchange docs are where you confirm the call.

npm install binance
npm install bybit-api
npm install okx-api
npm install bitget-api
npm install gateio-api
npm install kucoin-api
npm install coinbase-api
npm install bitmart-api
npm install @siebly/kraken-api
npm install @siebly/htx-api

Each package is JavaScript, with TypeScript types. There is not a separate Python or Go SDK in this set. Browser bundles exist for some of them. Private keys still belong on a server.

An OKX WebSocket order is a promise. The client opens and authenticates the socket for you. REST uses apiKey on the RestClient constructor. This client wants an accounts array, and the method is submitNewOrder, not submitOrder.

import { WebsocketAPIClient } from "okx-api";

const wsClient = new WebsocketAPIClient({
  accounts: [
{
apiKey: process.env.API_KEY,
apiSecret: process.env.API_SECRET,
apiPass: process.env.API_PASSPHRASE,
},
  ],
});

const order = await wsClient.submitNewOrder({
  instId: "BTC-USDT",
  tdMode: "cash",
  side: "buy",
  ordType: "market",
  sz: "0.1",
});

Use demo trading for that call until you mean to hit production. Set demoTrading: true on the same options object.

Binance spot over the WebSocket API:

import { WebsocketAPIClient } from "binance";

const wsClient = new WebsocketAPIClient({
  api_key: process.env.API_KEY,
  api_secret: process.env.API_SECRET,
  // testnet: true,
});

const order = await wsClient.submitNewSpotOrder({
  symbol: "BTCUSDT",
  side: "BUY",
  type: "MARKET",
  quoteOrderQty: "10",
});

Ed25519 keys can log in once on the Binance WebSocket API. HMAC and RSA sign every command. Futures orders on this class are submitNewFuturesOrder, not submitNewSpotOrder.

Kraken spot over WebSocket, from the package README. The symbol uses a slash.

import { WebsocketAPIClient } from "@siebly/kraken-api";

const wsApiClient = new WebsocketAPIClient({
  apiKey: process.env.API_KEY,
  apiSecret: process.env.API_SECRET,
});

const order = await wsApiClient.submitSpotOrder({
  order_type: "limit",
  side: "buy",
  limit_price: 26500.4,
  order_qty: 1.2,
  symbol: "BTC/USD",
});

Bitget’s V3 WebSocket order takes the product as the first argument:

import { WebsocketAPIClient } from "bitget-api";

const wsClient = new WebsocketAPIClient({
  apiKey: process.env.API_KEY,
  apiSecret: process.env.API_SECRET,
  apiPass: process.env.API_PASS,
  // demoTrading: true,
});

const order = await wsClient.submitNewOrder("spot", {
  orderType: "limit",
  price: "100",
  qty: "0.1",
  side: "buy",
  symbol: "BTCUSDT",
  timeInForce: "gtc",
});

Gate.io and HTX follow the same pattern: construct WebsocketAPIClient, then await a named method such as submitNewSpotOrder (Gate.io) or submitSpotOrder (HTX). KuCoin’s spot WebSocket order is submitNewSpotOrder. Read the method list in that package before you reuse a name from another one.

Keep config, the SDK client, and your own logic in separate modules. Test the parser without the network. Log the method and the error code, not the secret.

If the call is a WebSocket order, confirm both the class (WebsocketAPIClient) and the method on that exchange. A generated placeOrder() is a guess until you find it in the package.

They are instructions for a coding agent working on an exchange integration. They can name the language and the boundary of the task. They do not verify the code, run a bot, or make trading decisions. Check the result against the installed SDK and the exchange docs before you run it.

Name the package and a public method, for example MainClient.get24hrChangeStatistics from binance, or SpotClient.getTicker from @siebly/kraken-api. Ask for that call only. Run it with no keys. Compare the import and the arguments with the package examples before you add anything private.

Yes. Treat the file as a draft. Common failures in this set are a shared getTicker() that only some clients have, apiKey passed into Binance or Bybit, testnet: true on KuCoin or HTX, and WebsocketAPIClient imported from coinbase-api or bitmart-api.

No. None of these clients pause or queue calls to stay under an exchange cap. Your process has to do that, using the limits in the current exchange docs. If you retry, that policy is yours too. A WebSocket reconnect is not a retry of the request that failed.

Public data is the right first step on every package here, because it needs no key. A testnet, demo, or sandbox exists only on some clients, and the flag name differs. KuCoin and HTX do not expose one in these SDKs. Coinbase Advanced Trade does not have a sandbox. Passing those checks does not say anything about trading results.

The npm name, the import, the constructor options, the method, the symbol format, and the response fields. Then run the public call, or the demo flag that package documents. Keep secrets out of prompts, source, and logs.

Yes, where the package exports WebsocketAPIClient. You await a method such as submitNewOrder, submitNewSpotOrder, or submitSpotOrder, and the client sends it on a persistent socket. coinbase-api and bitmart-api do not offer that. Confirm the method in the package before you ship generated code, and try the promise on a demo or testnet account when that package has one.