--- title: "Siebly AI Skills for Trading: Developer Setup Guide" description: "Learn how to use Siebly AI skills for trading automation with Siebly SDKs in TypeScript and Node.js. Build safe, verified crypto REST and WebSocket workflows." canonical: "https://siebly.io/blog/siebly-ai-skills-for-trading-developer-setup-guide" --- # Siebly AI Skills for Trading: Developer Setup Guide Learn how to use Siebly AI skills for trading automation with Siebly SDKs in TypeScript and Node.js. Build safe, verified crypto REST and WebSocket workflows. ## Technical Disclaimer These articles are software engineering references for exchange API integrations. They are not financial, investment, legal, tax, compliance, or trading advice. Use public data, demo, testnet, or paper workflows first. Keep API credentials out of frontend code and disable withdrawal permissions for automation keys. ## Overview {#overview} Generated exchange code can look correct and still call a method that does not exist, or pass the wrong credential field. Siebly AI skills for trading automation help a coding agent stay on the task. They do not make the output correct. The Siebly SDKs are the JavaScript, TypeScript, and Node.js layer for these exchanges. They sign private requests, attach timestamps where the exchange requires them, and expose typed REST and WebSocket clients. They do not throttle you, and they do not retry a failed order for you. Start with public data. Move to a demo, sandbox, or testnet only where that package actually has one. Read the current package reference and the exchange docs before you trust a generated call. ## Key Takeaways {#key-takeaways} - Give the agent a small task: one exchange, one package, one public call, and a list of things it must not do. - Check the import, the class name, the option keys, and the method name against the SDK you installed. These ten packages do not share one interface. - The SDK signs requests and keeps WebSocket connections alive. Your code still owns rate limits, backoff, and whether a failed call should be sent again. - Public calls need no keys. Demo, sandbox, and testnet flags are not the same thing, and several packages have none. - Awaitable WebSocket orders exist only on packages that export `WebsocketAPIClient`. [coinbase-api](/sdk/coinbase/javascript) and `bitmart-api` do not. ## What Siebly AI Skills for Trading Automation Help Developers Build {#what-siebly-ai-skills-for-trading-automation-help-developers-build} An AI skill gives the agent context: language, exchange, and what the task is allowed to touch. The agent writes the application. The SDK talks to the exchange. The exchange docs say what the endpoint accepts today. None of those three checks the others. Before you follow a skill’s steps, read the current [AI skills for exchange integration](/ai) page. That page is the list of what the skills cover. After the agent writes code, compare it with the SDK you actually installed and with the exchange docs. ### What role does an AI skill play in an exchange integration? {#what-role-does-an-ai-skill-play-in-an-exchange-integration} 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](https://en.wikipedia.org/wiki/Algorithmic_trading) is a separate topic. This guide is about getting the integration code right. ### Why pair AI guidance with a Siebly SDK? {#why-pair-ai-guidance-with-a-siebly-sdk} 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](/sdk). ## How to Turn a Siebly AI Skill into a Verifiable Automation Workflow {#how-to-turn-a-siebly-ai-skill-into-a-verifiable-automation-workflow} Pick one public call and make the agent name the package. If the generated file imports a class that package does not export, throw it out. ### Define the task, exchange, and permitted data first {#define-the-task-exchange-and-permitted-data-first} 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`. ```js title="Imported example" 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. ```js title="Imported example" import { RestClientV5 } from "bybit-api"; const client = new RestClientV5(); const tickers = await client.getTickers({ category: "linear" }); ``` ```js title="Imported example" import { RestClient } from "okx-api"; const client = new RestClient(); const ticker = await client.getTicker({ instId: "BTC-USDT" }); ``` ```js title="Imported example" import { RestClient } from "gateio-api"; const client = new RestClient(); const ticker = await client.getSpotTicker({ currency_pair: "BTC_USDT", }); ``` ```js title="Imported example" import { SpotClient } from "kucoin-api"; const client = new SpotClient(); const ticker = await client.getTicker({ symbol: "BTC-USDT" }); ``` ```js title="Imported example" import { SpotClient } from "@siebly/kraken-api"; const client = new SpotClient(); const ticker = await client.getTicker({ pair: "XBTUSD" }); ``` ```js title="Imported example" import { SpotClient } from "@siebly/htx-api"; const client = new SpotClient(); const ticker = await client.getTicker({ symbol: "btcusdt" }); ``` ```js title="Imported example" import { CBAdvancedTradeClient } from "coinbase-api"; const client = new CBAdvancedTradeClient({}); const product = await client.getPublicProduct({ product_id: "BTC-USD", }); ``` ```js title="Imported example" import { RestClient } from "bitmart-api"; const client = new RestClient(); const ticker = await client.getSpotTickerV3({ symbol: "BTC_USDT" }); ``` ```js title="Imported example" 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. ### Review generated code against documented SDK behavior {#review-generated-code-against-documented-sdk-behavior} Reject the output if any of these are wrong: - Package name. Only Kraken and HTX are scoped: [@siebly/kraken-api](/sdk/kraken/javascript) and [@siebly/htx-api](/sdk/htx/javascript). The others install as [binance](/sdk/binance/javascript), [bybit-api](/sdk/bybit/javascript), [okx-api](/sdk/okx/javascript), [bitget-api](/sdk/bitget/javascript), [gateio-api](/sdk/gate/javascript), [kucoin-api](/sdk/kucoin/javascript), [coinbase-api](/sdk/coinbase/javascript), 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](/sdk) is the index. The exchange docs still decide what a field means. ## Choose the Right Integration Boundary: AI Skills, SDKs, and Exchange APIs {#choose-the-right-integration-boundary-ai-skills-sdks-and-exchange-apis} | Layer | Responsibility | Review focus | | --- | --- | --- | | AI skill | Tells the agent the task and the limits. | The skill does not run or verify the code. | | Siebly SDK | Signs requests, types the calls, and keeps WebSocket connections up, including resubscribe after a drop. | Confirm the class and method in that package. Do not assume a retry helper. | | Exchange documentation | Says which fields, weights, and error codes are current. | This is the source of truth for API behavior. | | Application | Decides when to call, when to wait, and when to stop. | Test throttling and failure handling yourself. | ### When should a workflow use an SDK instead of raw API calls? {#when-should-a-workflow-use-an-sdk-instead-of-raw-api-calls} 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`. ### What responsibilities remain with the application? {#what-responsibilities-remain-with-the-application} 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](/sdk/binance/javascript) - [bybit-api](/sdk/bybit/javascript) - [okx-api](/sdk/okx/javascript) - [bitget-api](/sdk/bitget/javascript) - [gateio-api](/sdk/gate/javascript) - [kucoin-api](/sdk/kucoin/javascript) - [@siebly/kraken-api](/sdk/kraken/javascript) (spot only) - [@siebly/htx-api](/sdk/htx/javascript) [coinbase-api](/sdk/coinbase/javascript) 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. ## How to Validate AI-Assisted Automation Safely Before Private Access {#how-to-validate-ai-assisted-automation-safely-before-private-access} Run the public call first. Save a fixture from a real response and test your parser against that fixture, plus a copy with a field removed. Live responses move around. A fixture does not. For streams, drop the socket and check that your own state survives a reconnect and a duplicate event. The client will try to reconnect. Your cache still has to tolerate the gap. If you use an awaitable WebSocket order, test the promise on a demo or testnet account where one exists. Cover the resolve, the reject, and a timeout. Kraken’s `WebsocketAPIClient` currently covers spot only. ### What should developers test in a simulation? {#what-should-developers-test-in-a-simulation} - 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. ### Where a demo, sandbox, or testnet actually exists {#where-a-demo-sandbox-or-testnet-actually-exists} Do not add `testnet: true` because another package has it. These are the flags that exist today: | Package | Safe environment in the SDK | | --- | --- | | [binance](/sdk/binance/javascript) | `testnet: true` for the test networks. `demoTrading: true` is separate: live market data, simulated fills. | | [bybit-api](/sdk/bybit/javascript) | `testnet: true` and `demoTrading: true` are separate options. Credentials use `key` and `secret`. | | [okx-api](/sdk/okx/javascript) | `demoTrading: true`. Also set `market` when the account is EEA (`EEA`) or US (`US`). Global is the default. | | [bitget-api](/sdk/bitget/javascript) | `demoTrading: true` on the V3 WebSocket API client. | | `bitmart-api` | `demoTrading: true` on `FuturesClientV2` and the futures WebSocket. Not a spot testnet switch. | | [gateio-api](/sdk/gate/javascript) | `useTestnet: true` on `WebsocketClient`. | | [@siebly/kraken-api](/sdk/kraken/javascript) | `testnet: true` on `DerivativesClient` only. Spot stays on the live host. | | [kucoin-api](/sdk/kucoin/javascript) | No testnet host in this SDK. | | [coinbase-api](/sdk/coinbase/javascript) | `useSandbox` on the Exchange and International clients. Advanced Trade, App, and Prime have no sandbox. | | [@siebly/htx-api](/sdk/htx/javascript) | No testnet or demo flag. Public reads are the safe first step. | A Bybit testnet client uses different option names from Binance: ```js title="Imported example" 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. ### How should API credentials be protected? {#how-should-api-credentials-be-protected} 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](/sdk) is where you pick the package. The exchange docs are where you confirm the call. ## Implement with Siebly AI Skills and the Relevant Exchange SDK {#implement-with-siebly-ai-skills-and-the-relevant-exchange-sdk} Install the package, open its examples, and only then ask the agent to write the integration. If the operation is missing from the package, check the exchange docs before you invent a method. ### Select a documented package for the target exchange {#select-a-documented-package-for-the-target-exchange} ```bash title="Imported example" 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. ### Public call, then a WebSocket order, on the package that has one {#public-call-then-a-websocket-order-on-the-package-that-has-one} 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`. ```ts title="Imported example" 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: ```ts title="Imported example" 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. ```js title="Imported example" 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: ```ts title="Imported example" 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. ### Move from a verified prototype to maintainable code {#move-from-a-verified-prototype-to-maintainable-code} 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. ## Build the Next Workflow with a Verified Integration Boundary {#build-the-next-workflow-with-a-verified-integration-boundary} Use a skill to keep the agent inside the task. Use the SDK that matches the exchange, with the class and option names that package actually exports. Treat the exchange docs as the source of truth when a field or error code is unclear. These SDKs cover JavaScript, TypeScript, and Node.js. They sign requests and maintain sockets. You still choose the rate limit policy and what happens after a failure. To begin, [review Siebly SDKs for your exchange integration](/). Start with one public call you can run without a key. ## Frequently Asked Questions {#frequently-asked-questions} ### What are Siebly AI skills for trading automation? {#what-are-siebly-ai-skills-for-trading-automation} 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. ### How do I use an AI skill with a Siebly exchange SDK? {#how-do-i-use-an-ai-skill-with-a-siebly-exchange-sdk} Name the package and a public method, for example `MainClient.get24hrChangeStatistics` from [binance](/sdk/binance/javascript), or `SpotClient.getTicker` from [@siebly/kraken-api](/sdk/kraken/javascript). 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. ### Can AI skills generate exchange API integration code? {#can-ai-skills-generate-exchange-api-integration-code} 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](/sdk/coinbase/javascript) or `bitmart-api`. ### Do Siebly SDKs automatically handle exchange rate limits? {#do-siebly-sdks-automatically-handle-exchange-rate-limits} 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. ### Is it safe to test an AI-generated exchange workflow with public data or testnet? {#is-it-safe-to-test-an-ai-generated-exchange-workflow-with-public-data-or-testnet} 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. ### What should I verify before using generated JavaScript or TypeScript code? {#what-should-i-verify-before-using-generated-javascript-or-typescript-code} 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. ### Can a WebSocket API support awaitable exchange operations? {#can-a-websocket-api-support-awaitable-exchange-operations} 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. ## Related articles - [Building a Crypto Dashboard with Node.js: A Practical Guide](/blog/building-a-crypto-dashboard-with-nodejs-a-practical-guide) - [Event-Driven Crypto Trading Guide for Node.js](/blog/event-driven-crypto-trading-guide-for-nodejs) - [Node.js Trading System Architecture: 2026 Guide](/blog/nodejs-trading-system-architecture-2026-guide) ## Related Siebly Resources - [Binance JavaScript SDK](/sdk/binance/javascript) - [Bybit JavaScript SDK](/sdk/bybit/javascript) - [OKX JavaScript SDK](/sdk/okx/javascript) - [Siebly SDK directory](/sdk) - [Siebly AI Prompt Framework & Skills](/ai)