Osiris API

The same real-time engine the site runs on: candles, computed metrics, order-book walls, market structure and alerts for 500+ Binance USDT perpetuals, over plain authenticated REST and WebSocket.

Everything you see on Osiris (the screener rankings, the fear & greed dial, the support/resistance lines on charts, the density walls, the alerts firing in real time) is computed by our own market engine from the live Binance futures tape. The Developer plan opens that engine to your code. There is no separate "API pipeline": every endpoint reads the exact same in-memory data the site itself renders from, at the same freshness. If the screener shows it, the API returns it, at the same moment.

That design has a practical consequence worth understanding: you are not consuming a delayed or re-aggregated copy of Binance. Candles include the live in-flight bar, metrics are recomputed on 10-60 second sweeps across the whole market, density walls are rescanned every 2 seconds, and the WebSocket stream pushes ticks the moment our ingest flushes them. Building a dashboard, a signal bot or a research notebook against this API gives you the same view a trader has with the site open.

Base URL

All REST endpoints live under this base
https://osiristrader.com/api

All endpoints are versioned under /v1. We treat the v1 response shapes as a contract: fields are added over time (your parser should ignore unknown keys), but existing fields are not renamed or removed within v1.

Exchanges

Every data endpoint answers for one venue per request. Pass ?exchange= with a venue id (binance, bybit, okx, bitget) to read that exchange's market; omit it and the default venue (Binance) answers, which is exactly what every integration written before multi-exchange support gets, unchanged. Venue-scoped responses echo the venue in an exchange field.

The same pair is a different instrument on each venue, with its own price, volume, funding and order book, and each venue lists pairs the others don't (tokenized stocks like AAPLUSDT trade on Bybit, OKX and Bitget only). Fetch Symbols per venue to learn what each one serves; a symbol asked of a venue that doesn't list it is a 404, and an unknown venue id is a 422 whose message names the available exchanges.

Quickstart

Grab a key in Settings → Developer → Configure (requires the Developer plan), then make your first call:

Your first request: the whole market in one call
curl "https://osiristrader.com/api/v1/market" \
  -H "Authorization: Bearer osk_YOUR_KEY"

That single response contains a live summary of every tracked pair: price, 24h change, rolling volumes, volatility, taker delta, funding and BTC correlation, recomputed every 10 seconds. From there, three directions are typical:

  • Screening & discovery. Rankings gives you every pair sorted by any metric we compute; Market overview adds breadth, fear & greed and dominance for regime context.
  • Per-pair analysis. Candles, Metrics, Levels and Densities give you everything the chart page knows about one symbol.
  • Automation. The WebSocket stream replaces polling with push, and Alerts & webhooks let our engine watch a condition 24/7 and call your server the moment it triggers.

The data pipeline behind the API

It helps to know where the numbers come from. Our ingest keeps a persistent WebSocket mesh to Binance futures covering every USDT perpetual, and maintains closed candles plus a live in-flight bar per symbol per timeframe in memory. On top of that, a metrics engine sweeps the whole market on fixed cadences and computes each family: volatility estimators, surge detection, order-flow statistics, BTC correlation, funding analytics, trend scoring and market-structure levels. A separate detector holds full order books for every pair and hunts for density walls. The REST layer is deliberately thin: it authenticates you, reads the current computed state and returns it.

DatasetRecomputedEndpoint
Live candleson every trade (flushed ≤300 ms)/v1/candles, WebSocket
Market snapshotevery 10 s/v1/market, /v1/market/overview
Metric familiesevery 30 s/v1/metrics, /v1/rankings
S/R levelsevery 60 s/v1/levels
Fundingevery 60 s/v1/metrics, /v1/funding
Density wallsevery 2 s/v1/densities
Alertsevaluated on every live tick/v1/alerts + webhooks

Response conventions

  • Every response is JSON. Collection payloads live under a data key; envelope fields like symbol, interval or asOf sit beside it.
  • Timestamps are Unix milliseconds (the native resolution of the tape). Alert timestamps in REST responses are ISO-8601 strings.
  • Symbols are always uppercase pair names (BTCUSDT). Requests accept any case.
  • Numeric metric values are plain JSON numbers; a metric that cannot be computed yet (young listing, quiet tape) is simply absent rather than null or 0; treat missing as "unknown", not as zero.

Versioning & stability

The metric values evolve as we tune the engine; that is the product improving, not an API change. The shape of responses is stable within v1. When a breaking change is unavoidable, it ships as /v2 alongside v1, with a deprecation window announced on the blog and in the changelog before v1 endpoints are ever retired.

Something missing? The API surface grows with the site. If your integration needs a dataset you can see on Osiris but not in the API, tell us via the feedback form. "Expose what the UI already shows" requests are usually quick to ship.