Hooking your stack into CoinGlass's derivatives data

Roughly thirty centralized exchanges feed CoinGlass — Binance, OKX, Bybit, Deribit, Bitget, Hyperliquid, Kraken, Bitmex, Bitfinex, Huobi, Coinbase, and a long tail of smaller venues — and the app fans that into open interest, funding rates, liquidations, long/short ratios and ETF flows. The user gets one screen across all of it. An integrator wants the underlying cells, not the screen.

What CoinGlass actually holds

The screens map cleanly to domains once you stop thinking in tabs and start thinking in fact tables. Per the live dashboards as of late May 2026:

How we get to it

Three routes apply here, and the right pick depends on which slice of the domain table you actually need.

1. Authorized interface integration over the published market-data surfaces

This is the route for everything on the aggregated side: OI, funding, liquidations, long/short, ETF flows, market cap. The data is published, the screens are public, and ingestion is a question of cadence, rate budget and per-venue field reconciliation. Effort: moderate. Durability: high — the surfaces are stable across the product's history, and CoinGlass exposes years of depth on the major pairs. The studio sets up rate-limit-aware polling with a delta cache so re-runs cost the same as steady-state runs.

2. User-consented credential access for the account-gated surfaces

The portfolio, watchlist and custom alerts sit behind the account. The login is required; that part isn't optional. The user provides their session (or you do, if the integration is internal), and the studio handles session lifecycle and revocation detection. Effort: lower than route 1 in lines of code, higher in operational care. Durability depends on the auth flow staying stable; the build includes a canary that flags drift before silent failure.

3. Native export where present

Useful for one-off backfills and audit snapshots. Not a primary route for live work, but cheap to wire and useful as a reconciliation against route 1.

The route to start on is the first one. The aggregated surface is where the value sits, the schema work is the same regardless of which subset you need, and the consented session model from route 2 fits cleanly into the same warehouse once it's there.

Where the build needs care

Three things that an honest CoinGlass integration accounts for, and that we handle as part of the engagement rather than asking you to pre-solve:

• Per-venue OI semantics. Open interest is reported in different units across exchanges — some venues quote in coin notional, some in USD, some split the perp and quarterly books separately, some collapse them. We reconcile into one canonical OI table per coin, venue and timestamp so a Binance row and an OKX row are actually comparable rather than just neighbouring in a spreadsheet.
• Funding settlement cadence. Most majors settle every 8 hours. A few venues use 4-hour windows. Hyperliquid runs hourly. We pin the ingestion to the venue's own schedule so averages don't smear settlements across boundaries and APR conversions stay correct per row.
• Hyperliquid vs the centralized aggregate. Hyperliquid is on-chain — its order book is public chain state, and CoinGlass shows it alongside CEX venues but the numbers come from a different reality. We treat that as a separate ingestion that reconciles against the aggregate; the small disagreement at short windows is itself the interesting signal.
• Session-aware sync for account paths. The portfolio and alerts pull off a login. We design the sync around the session lifetime so consent revocation surfaces within minutes, not at the next 24-hour tick, and so a logged-out user doesn't produce a row of empty deltas.

What a funding-rate pull looks like

Illustrative — exact field names and pagination shape are confirmed during the build against the live surface, not asserted here.

async def pull_funding(coin: str, since: datetime, http) -> AsyncIterator[dict]:
    # one row per (coin, venue, settlement_at), APR-normalized
    raw = await http.get(
        f"{BASE}/funding/history",
        params={"symbol": coin, "interval": "8h", "from": int(since.timestamp())},
        headers=AUTH,
    )
    for venue, rows in raw["data"].items():
        for r in rows:
            interval_h = int(r.get("interval", "8h").rstrip("h"))
            yield {
                "coin": coin,
                "venue": venue,
                "settlement_at": iso(r["t"]),
                "rate_period": float(r["r"]),
                "rate_apr": float(r["r"]) * (24 / interval_h) * 365,
                "interval_h": interval_h,
            }
            # backoff respects venue-side and aggregator-side budgets;
            # the canary watches for sudden schema drift on r["r"] / r["t"].

What the build hands over

The deliverable is shaped around what you actually need to query against later, not around endpoint count:

• A normalized SQL schema with one canonical coin dimension, separate fact tables for OI, funding, liquidations, long/short and ETF flows, and per-venue dimension tables for the small differences that matter.
• Runnable ingestion source in Python or Node, with the polling cadence configured per metric and per venue.
• A replay and backfill harness for the historical depth CoinGlass exposes — years for the major pairs, shorter for newer venues like Hyperliquid.
• Account-gated portfolio sync with revocation handling, if that slice is in scope.
• An OpenAPI spec for the hosted endpoint variant, so your callers can generate clients.
• Tests against captured fixtures plus a small set of live-smoke checks that won't run up the rate budget in CI.
• Interface documentation that names the per-venue quirks rather than pretending they don't exist.

Authorization and the privacy regime

The aggregated derivatives side runs against published data; every fetch is logged with a request id and a timestamp so the activity is auditable on your side. The account-gated paths only flow with the user's authorization, scoped to the columns the integration needs, with a documented revocation path. EU users pull GDPR into the picture; consent records and data-minimization decisions are kept in writing as part of the handover. Upstream exchange API keys that a user has connected inside CoinGlass stay inside the user's session — we don't ask for them and the build doesn't store them. NDA on request before any traffic capture begins.

Cost and how this runs

A working CoinGlass pull mapped to your own schema lands in one to two weeks. Source-code delivery starts at $300; you pay after delivery, once it runs against your data and you're satisfied. If a hosted endpoint suits your team better than running another ingestion, we operate the pull on our side and you pay per call with no upfront fee. Either way the first step is the same: send the app name and what you want from the data over to /contact.html and we'll come back with a scoped build plan.

What the app surfaces look like

Six screens from the current Play Store listing, used as interface evidence during scoping. Click for full size.

Other apps in this corner of the market

Customers looking at a CoinGlass integration usually have at least one of these in the picture too. Names listed as ecosystem context, not ranking — they often end up side by side in the same warehouse.

• Coinalyze — aggregated derivatives dashboard covering OI, funding and CVD; closest functional peer on the data side.
• CryptoQuant — on-chain plus exchange flow analytics; pairs well as the on-chain half of a combined feed.
• Coinank — derivatives-focused dashboard from APAC, very similar shape to CoinGlass.
• Buildix — Hyperliquid-heavy screener with cross-venue orderflow, useful when the strategy is perp-DEX-led.
• TradingView — chart-first platform that customers commonly want reconciled against the derivatives feed.
• DexScreener — DEX pair coverage; complements CoinGlass for a full CEX-plus-DEX picture.
• Glassnode — on-chain network metrics; sometimes ingested next to CoinGlass for the macro view.
• Velo Data — institutional derivatives data feed; the comparable enterprise alternative on the same domain.

Sources used for this mapping

The mapping above was checked against the live CoinGlass dashboards on 30 May 2026 — the funding-rate page, the BTC futures market page, and the open-interest screens — and against the current Play Store listing for the Android build. Deep links to the surfaces actually read:

• Google Play listing for CoinGlass (com.coinglass.android)
• CoinGlass funding rate dashboard
• BTC futures market data page (liquidations, OI, long/short)
• BTC open interest page (per-exchange breakdown)

Mapping by OpenBanking Studio's derivatives data desk, May 2026.

Questions integrators ask about CoinGlass

Which exchanges does the derivatives surface actually cover?

Around thirty centralized venues on the perp and futures side — Binance, OKX, Bybit, Deribit, Bitget, Kraken, Bitmex, Bitfinex, Huobi, Coinbase, and Hyperliquid among them. Coverage per metric varies. Some venues report aggregated open interest but not a granular liquidation stream; some report funding only on the major pairs. We document that in the schema notes for your specific scope.

Are the liquidation heatmaps available as numeric cells or only as rendered images?

The heatmap is a numeric grid of price level by time by notional. The build pulls the cell data, not the PNG. The image is one rendering. You can re-render it however you want, or skip the picture entirely and pipe the cells into your own risk model.

Do you handle Hyperliquid the same way as a centralized venue feed?

No. Hyperliquid is on-chain. The order book and trade stream are public chain state. We treat the Hyperliquid surface as a separate ingestion that reconciles against the centralized aggregate, because the two disagree at short windows and the discrepancy is itself useful for arbitrage and flow attribution.

Can we ingest the ETF flow data alongside derivatives on one schedule?

Yes, in one warehouse but on different schedules. ETF flows settle daily per issuer (the BTC and ETH books are the deepest; SOL and XRP entries exist where the products list). Derivatives metrics are per-minute or per-tick depending on metric. The build defines one canonical coin dimension and lets each fact table reference it without coupling cadences.