Common Workflows

Start with Your Question

CoinGlass brings together open interest, funding rates, liquidations and order flow across markets, alongside liquidation models, ETF data and public wallet positions. The four workflows below explain what you can observe with these datasets and how to use them in your own tools.

Choose a plan that meets the highest requirement among the endpoints in a workflow. Commercial products require Standard or above. See API Plans and Permissions for pricing, request limits and historical data ranges.

Understand the Market Structure Behind Price Moves

Your question: When price changes, does open interest change too? What do funding rates, top trader positions and taker buying/selling show?

How to combine them:

1. Select a coin, exchange scope and interval. Price and top trader ratios use a specified pair; aggregated open interest, weighted funding rates and aggregated CVD each have their own market coverage.
2. Use price as the time axis and display open interest, funding, long/short ratios and CVD alongside it. For example, when price rises, observe whether open interest also grows, how funding changes, and the direction of the taker buy/sell difference.
3. Retain each indicator's scope and units in your coin monitoring dashboard, then test the relationships you observe through historical research.

Plan requirements: Basic open interest, funding, long/short ratios and price history start at Hobbyist; aggregated CVD starts at Startup. See Time Intervals and interval for interval permissions on applicable candle endpoints.

Data definitions: Open interest value is not net capital inflow, and long/short ratios are not taker trade volume. Aggregated markets and individual pairs cover different scopes. Funding rate candles include predicted rates and cannot be used directly as actual settlement cash flows. CVD's starting point is determined by the requested range; align starting points and units for cross-market comparisons.

Monitor Key Price Levels and Market Risk

Your question: Where does the model show liquidation concentrations near the current price? Where are resting buy and sell orders? Are actual liquidations increasing?

How to combine them:

1. Relate liquidation distributions and order book data for the same underlying asset. Display modeled intensity and resting order quantities separately, labeling the exchanges and pairs covered by each dataset.
2. Add actual liquidation orders, displaying events by time, side and value. Generate alerts using thresholds defined for your application.
3. Compare model distributions, order book changes and actual liquidations before and after price moves to build an intraday risk monitoring record. Add Liquidation Max Pain for a quick view of key modeled price levels.

Plan requirements: Order book heatmaps, large orders, and REST/WebSocket liquidation orders start at Standard. Liquidation heatmaps, maps and max pain start at Professional. The full combination above requires Professional or above.

Data definitions: Liquidation intensity is a model output, not an actual or expected liquidation amount. Model distributions do not guarantee that price will reach a particular level. Resting orders may be filled or canceled; actual liquidation amounts come from forced-liquidation orders. Display models separately. When overlaying data, convert seconds/milliseconds and quantity units according to each endpoint's field definitions.

Track Flows and Large Positions

Your question: How are ETF flows changing? What large positions are Hyperliquid wallets opening or closing, and what do they currently hold?

How to combine them:

1. Organize ETF flows by UTC date into charts showing totals and fund-level details.
2. Display whale alerts by wallet, coin and time. Query current positions to add position sizes and risk-related fields.
3. Show fund flows and large wallet positions in separate sections of the same research dashboard, with their respective update times, to produce daily reports or ongoing monitoring records.

Plan requirements: ETF endpoints start at Hobbyist. Hyperliquid whale alerts, whale positions and wallet positions start at Startup. Commercial products require at least Standard.

Data definitions: ETF flows and wallet position changes measure different things. They cannot be added together or used to infer that funds moved between them. Whale alerts do not contain full position details, and current positions cannot replace a complete history. A public wallet address alone does not establish a known institutional identity.

Daily ETF Flow Report

1. Organize total net flows and fund details by the UTC date of timestamp. flow_usd is a USD value: positive for net inflows and negative for net outflows.
2. Match each detail record's etf_ticker to ticker in the BTC ETF List or ETH ETF List to add fund names, types and current AUM. Match only funds actually returned in the flow data.
3. Total net flows already include the fund details; do not add them again. Include update_timestamp with current AUM, which is not historical daily AUM. Leave missing dates empty and replace records for the same date when disclosures are updated. These endpoints start at Hobbyist; commercial products require at least Standard.

Test Strategies and Integrate Data into Your Systems

Your question: How have these indicators behaved historically? How can historical research and continuously updated data feed your own research or trading systems?

How to combine them:

1. Fix the asset, market scope, interval and units. Retrieve history using each endpoint's time parameters and pagination rules, retaining the source, timestamps and missing-data status.
2. Calculate research features from completed intervals, define backtest periods and test your own rules. When downloading CVD in segments, continue the cumulative calculation using taker buys minus taker sells. Do not use funding rate candles directly as actual settlement cash flows.
3. In production, maintain data at each REST endpoint's update cadence. Subscribe to supported WebSocket channels as needed, handling heartbeats, reconnections and deduplication. Real-time coverage is defined in each channel's documentation.

Plan requirements and historical range: Basic historical endpoints start at Hobbyist, CVD at Startup, and WebSocket at Standard. The minimum interval for applicable basic candle endpoints is 4 hours on Hobbyist, 30 minutes on Startup, and 1 minute on Standard and above. Available history varies by data type, exchange, pair and plan; see API Plans and Permissions.

Integration boundaries: CoinGlass provides data; your system implements strategy calculations, backtesting and trade execution. REST and WebSocket do not guarantee matching historical coverage for every event. For example, liquidation orders can be queried within the last 7 days; design storage and recovery for other channels according to their documentation. Do not deduplicate merged data by timestamp alone.

Integration and Data Alignment

• Include CG-API-KEY in REST request headers. Check both the HTTP status and business code before reading data; see Quickstart.
• Check supported futures pairs and spot pairs, then confirm that the selected data endpoint covers that market. Label the scope of cross-exchange aggregates, individual pairs and on-chain wallets separately.
• Convert seconds/milliseconds, coin quantities/USD and percentages according to each endpoint's field definitions. For segmented historical queries, see Timestamps and Pagination.
• See WebSocket Getting Started for connections and heartbeats, Error Codes and Rate Limits for throttling and error handling, and Endpoint Overview for all endpoints.