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
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:
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.
| Dataset | Recomputed | Endpoint |
|---|---|---|
| Live candles | on every trade (flushed ≤300 ms) | /v1/candles, WebSocket |
| Market snapshot | every 10 s | /v1/market, /v1/market/overview |
| Metric families | every 30 s | /v1/metrics, /v1/rankings |
| S/R levels | every 60 s | /v1/levels |
| Funding | every 60 s | /v1/metrics, /v1/funding |
| Density walls | every 2 s | /v1/densities |
| Alerts | evaluated on every live tick | /v1/alerts + webhooks |
Response conventions
- Every response is JSON. Collection payloads live under a
datakey; envelope fields likesymbol,intervalorasOfsit 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
nullor0; 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.