Paper Trading Bot JavaScript: A Professional Node.js Engineering Guide

Non-blocking I/O lets a single Node.js process handle simultaneous streams from multiple venues. In a blocking workflow, one slow HTTP call stalls everything. The event loop hands I/O to the kernel and keeps processing ticks. TypeScript then locks down request and response shapes so a candle close is not silently a string one day and a number the next. You can run this on a current Node.js LTS with TypeScript. The SDKs do not require a specific compiler version.

Environment parity is the whole point. Build the paper trading bot with production clients such as bybit-api or okx-api. Your call sites stay the same when you later enable demo trading. The SDKs sign requests, keep timestamps in recvWindow, and reconnect WebSockets. They do not invent a common order object across Binance, Bybit, and OKX. You still write a thin adapter if you want one strategy talking to several venues.

Rate limiting is also on you. None of these clients auto-sleep or queue traffic. That is intentional. You decide how close to the exchange cap you want to sit.

The Data module seeds indicators with historical OHLCV over REST, then keeps them warm with WebSocket candles. Typed params from okx-api or binance catch your mistakes at compile time. They do not shield you if the exchange changes a payload overnight. Cache locally during development so you are not hammering public kline endpoints. That also lines up with FINRA rules for algorithmic strategies around supervision and control of automated logic.

Public kline calls need no keys:

import { MainClient } from "binance";
import { RestClientV5 } from "bybit-api";
import { RestClient } from "okx-api";

const binance = new MainClient();
const bybit = new RestClientV5();
const okx = new RestClient();

const binanceKlines = await binance.getKlines({
  symbol: "BTCUSDT",
  interval: "1m",
  limit: 200,
});

const bybitKlines = await bybit.getKline({
  category: "spot",
  symbol: "BTCUSDT",
  interval: "1",
  limit: 200,
});

const okxCandles = await okx.getCandles({
  instId: "BTC-USDT",
  bar: "1m",
  limit: "200",
});

Same idea, three different contracts. Bybit wants category. OKX wants instId and bar. Binance wants symbol and interval. That is why the strategy should consume your own candle type, not the raw exchange row.

bitget-api uses RestClientV3.getCandles({ symbol: 'BTCUSDT', category: 'SPOT', interval: '1m' }). kucoin-api uses SpotClient.getKlines({ symbol: 'BTC-USDT', type: '1day' }). gateio-api uses RestClient.getSpotCandles(). coinbase-api uses CBAdvancedTradeClient.getProductCandles(), and that one is a private CDP call, not a public unauthenticated feed.

Throttle this layer yourself. A 429 is your problem, not the SDK's.

The execution module is a virtual ledger: positions, balances, realized PnL. A useful paper trading bot also models slippage, fees, and the gap between intent and fill. During local simulation you do not need to send orders anywhere. You apply fills against the last public trade or book.

When you later send real demo or testnet orders, use the same state machine you will use in production. WebsocketAPIClient is the awaitable path. It looks like REST, but the command rides a persisted WebSocket and the Promise resolves when the exchange ack comes back. That is order placement latency, not market-data events. Market data still arrives on update or message.

Bybit example, taken from the SDK's WS API client sample:

import { WebsocketAPIClient } from "bybit-api";

const wsApi = new WebsocketAPIClient({
  key: process.env.API_KEY_COM,
  secret: process.env.API_SECRET_COM,
  // testnet: true,
  // demoTrading does not support Bybit's WS API. Use REST for Bybit demo orders.
});

const order = await wsApi.submitNewOrder({
  category: "linear",
  symbol: "BTCUSDT",
  orderType: "Limit",
  qty: "0.001",
  side: "Buy",
  price: "50000",
});

OKX needs the passphrase as well (apiPass / apiPassphrase). Bitget and KuCoin do too. Binance does not.

binance and bybit-api give you TypeScript interfaces for that venue's requests and responses. They stop you from sending qty when Binance wants quantity. They do not map Bybit's submitOrder onto Binance's submitNewOrder.

import { MainClient } from "binance";
import { RestClientV5 } from "bybit-api";

const binance = new MainClient({
  api_key: process.env.API_KEY_COM,
  api_secret: process.env.API_SECRET_COM,
});

const bybit = new RestClientV5({
  key: process.env.API_KEY_COM,
  secret: process.env.API_SECRET_COM,
  parseAPIRateLimits: true,
});

const used = binance.getRateLimitStates();

For a walkthrough of REST plus WebSocket setup, see the Bybit JavaScript tutorial.

WebSocket management is the painful part: heartbeats, pong timeouts, the daily disconnect some venues force, resubscribe after a drop. Siebly clients do that. You subscribe, then listen.

Public Bybit klines:

import { WebsocketClient } from "bybit-api";

const ws = new WebsocketClient();

ws.on("update", (data) => {
  console.log("tick", data);
});

ws.on("reconnect", ({ wsKey }) => {
  console.log("reconnecting", wsKey);
});

ws.on("reconnected", (data) => {
  console.log("reconnected", data?.wsKey);
});

ws.subscribeV5(["kline.5.BTCUSDT", "kline.5.ETHUSDT"], "spot");

Public OKX candles:

import { WebsocketClient } from "okx-api";

const ws = new WebsocketClient();

ws.on("update", (data) => {
  console.log("tick", data);
});

ws.subscribe({
  channel: "candle1m",
  instId: "BTC-USDT",
});

Binance subscribe is itself a Promise (await wsClient.subscribe([...topics], 'main')). That only means the subscribe command finished, not that you got a fill. For REST-like trading over the socket, use WebsocketAPIClient. The Binance JavaScript tutorial covers live price feeds.

Look-ahead bias is using data that would not have been available at the decision time. Reading the high or low of a candle before it closes is the classic version. Process ticks in order. Each loop iteration only sees the current tick and what came before it.

Out-of-sample testing is the other check. Split history in two. Build on the first set, validate on the second. If it only works on the first, the logic is fitted to that window. Do this before you spend time on a testnet.

A sim that fills at the signal price with zero delay is lying. Add latency between signal and confirmation. Live that gap is milliseconds to seconds, depending on the network and the venue.

Fees belong in the ledger too. Maker and taker rates differ by exchange and VIP tier. Siebly AI patterns are a starting point for order-intent workflows. The Siebly SDK catalog is where the actual clients live.

Hard caps on order size, total exposure, and order rate are not optional. They are the circuit breaker when the strategy goes stupid. Broader patterns are in the algorithmic trading system architecture guide.

Use least-privilege API keys. Disable withdrawals on anything a bot can touch. Store secrets in environment variables. Do this on testnet too, or you will skip it on live.

Siebly AI helps coding agents write reconnect and partial-fill handling. The clients in the Siebly SDK catalog are the actual sockets and REST wrappers. That is the layer you want under a paper trading bot before you point it at live market data.

Yes for the millisecond-level work most systematic bots actually do. Node.js handles concurrent sockets without blocking the loop. V8 is good at JSON. It will not beat C++ on nanosecond matching-engine work. It will hold dozens of WebSocket streams and a strategy loop without drama.

Siebly packages used in production: binance, bybit-api, okx-api, bitget-api, kucoin-api, gateio-api, coinbase-api, bitmart-api, @siebly/kraken-api, and @siebly/htx-api. They type that venue's REST and WebSocket APIs and sign private calls. They do not give you one identical order method across all ten. That adapter is yours.

You throttle. The SDKs sign and send. They do not queue. On Binance, call client.getRateLimitStates() and read x-mbx-used-weight / x-mbx-used-weight-1m. On Bybit, set parseAPIRateLimits: true and read rateLimitApi on the response. Token bucket or a simple FIFO queue is the usual pattern. Watch 429s anyway. Demo and testnet caps are often lower than live.

Where the exchange has one, yes. Set the flag listed above. Do not paste a custom base URL unless you are overriding for a proxy. KuCoin and HTX have no demo flag. Coinbase Advanced Trade has no sandbox. Bybit demo trading does not speak the WebSocket API, so demo orders go through RestClientV5.

Backtesting replays history. Paper trading consumes a live stream and simulates fills without capital. Backtests catch logic that only works on a particular window. Paper trading catches reconnects, clock skew, and the fact that the next tick is not free.

Strict chronological processing. The strategy only sees data with timestamps at or before now. Do not use a candle's high, low, or close until that candle is closed. Keep the data module from leaking future rows into the strategy.

Yes. MainClient.getKlines() on binance, RestClientV5.getKline() on bybit-api, RestClient.getCandles() / getHistoricCandles() on okx-api, RestClientV3.getCandles() on bitget-api, SpotClient.getKlines() on kucoin-api, RestClient.getSpotCandles() on gateio-api. Seed indicators from REST, then switch to the socket.

gateio-api and coinbase-api are the same story as Binance: signing, timestamps, listen-key style persistence, reconnect, typed params. Coinbase Advanced Trade uses JWT via jose, not a simple HMAC header. You do not want to maintain that by hand. The SDK will not design your strategy or your kill switch.