Trade Flow Imbalance Detector
Overview
This tutorial shows how to build a real-time Trade Flow Imbalance Detector using CoinAPI’s Market Data WebSocket trade stream.
The application will:
- connect to the WebSocket feed
- subscribe to live
trademessages - track trades in a rolling window
- calculate buy and sell pressure using
taker_side - apply filters so the signal is more reliable
- compare pressure against recent price movement
- print a live signal in the terminal
By the end, the script will help users answer questions like:
- Are buyers or sellers dominating right now?
- Is the pressure strong enough to matter?
- Is price moving in the same direction as the flow?
- Is the signal persistent or only temporary?
What this detector measures
Each trade includes:
pricesizetaker_side
The script uses those fields to calculate:
- Buy Volume = sum of sizes where
taker_side = BUY - Sell Volume = sum of sizes where
taker_side = SELL - Net Imbalance =
Buy Volume - Sell Volume - Imbalance Ratio =
(Buy Volume - Sell Volume) / (Buy Volume + Sell Volume)
A positive ratio means buyer-initiated trades dominate.
A negative ratio means seller-initiated trades dominate.
To make the output more useful, this tutorial adds:
- a minimum trade count
- a signal persistence rule
- price confirmation
What you will build
This tutorial uses one active symbol to keep the output readable:
BINANCE_SPOT_AAVE_USDT
You can replace it later with another symbol.
Prerequisites
You need:
- Node.js installed
- a CoinAPI API key
- terminal access
This tutorial uses the Market Data WebSocket endpoint:
Step 1 — Create the project folder
Open your terminal and run:
Step 2 — Create package.json
Create a new file named package.json and paste this into it:
Save the file.
Step 3 — Install dependencies
Run:
This installs:
wsfor the WebSocket clientdotenvfor loading your API key from.env
Step 4 — Create .env
Create a new file named .env and paste this into it:
Replace YOUR_API_KEY_HERE with your actual API key, then save the file.
Step 5 — Create index.js
Create a new file named index.js and paste the full script below.
Save the file.
Step 6 — Understand the incoming trade message
A trade message from CoinAPI includes fields like:
CoinAPI’s docs and examples show this same trade event structure, including taker_side, price, size, symbol_id, timestamps, and sequence.
For this tutorial:
sizeis the amount tradedtaker_sidedecides whether the trade counts as buy flow or sell flowtime_coinapiis used for the rolling windowpriceis shown as the latest price in the terminal
Step 7 — Run the script
In your project folder, run:
You should see:
After trades begin streaming, the terminal will update continuously.
Step 8 — What the script does in real time
Once running, the script:
- connects to the WebSocket endpoint
- subscribes to
tradedata for your selected symbol - receives trades as they happen
- stores them temporarily in memory
- removes trades outside the rolling window
- calculates:
- buy volume
- sell volume
- trade counts
- price change within the window
- imbalance ratio
- evaluates the signal using:
- minimum trade threshold
- persistence check
- price context
- prints a live summary every second
Step 9 — Sample terminal output
Because this uses live data, your output will vary. A sample might look like:
This output shows:
- more sell trades than buy trades
- higher sell volume
- negative imbalance ratio
- price moving downward
Together, these indicate consistent sell-side pressure.
Step 10 — How the rolling window works
The script only considers trades within a recent time window:
This means:
- only trades from the last 30 seconds are used
- older trades are removed continuously
This keeps the signal focused on recent activity.
Why this matters
- short window → faster but noisier
- longer window → smoother but slower
Step 11 — Why minimum trade count is used
The script requires a minimum number of trades:
Purpose
- avoids signals based on very few trades
- prevents misleading results on low activity
If the number of trades is below this threshold, the signal will show:
Step 12 — Why persistence is used
The script checks whether the same directional signal appears repeatedly before confirming it.
Purpose
- avoids reacting to brief spikes
- ensures the signal is sustained
Without this, a single burst of trades could incorrectly appear as a strong signal.
Step 13 — Why price context is included
The script compares:
- first price in the window
- last price in the window
This allows it to determine whether:
- pressure aligns with price movement
- or if there is divergence
Examples
- sell pressure + price dropping → strong confirmation
- sell pressure + price rising → possible absorption
- buy pressure + flat price → weak signal
This adds important context to the imbalance.
Step 14 — Change the symbol
To use a different asset, edit this section:
Example:
Step 15 — Adjust sensitivity
You can tune the detector depending on your needs.
Faster, more reactive
More stable
Lower activity markets
High-confidence signals
Stricter persistence
Step 16 — Troubleshooting
No trades appearing
- try a more active symbol
- check symbol format
Signal stuck at “Insufficient Data”
- lower minimum trade threshold
- or increase window size
Output updates too quickly
- increase window size
- increase persistence cycles
Step 17 — Project structure
Your folder should look like:
trade-flow-imbalance-demo/
├── .env
├── index.js
├── package-lock.json
└── package.json
Congratulations!
You now have a real-time Trade Flow Imbalance Detector that goes beyond basic volume tracking.
You were able to:
- stream live trade data using WebSocket
- classify trades into buy and sell pressure
- calculate imbalance in a rolling time window
- filter out weak signals using minimum trade thresholds
- confirm signals using persistence
- interpret pressure using price movement
This creates a more reliable and practical signal that can be used for:
- short-term market monitoring
- momentum confirmation
- identifying potential turning points
From here, you can extend this by:
- adding charts for visualization
- tracking multiple symbols separately
- triggering alerts when strong pressure persists
- combining this with order book data for deeper analysis
You now have a solid foundation for building real-time trade flow analytics.