Snapshot

#The principle

Each parameter of the request is a field name, and its value the depth requested (a number of rows, of minutes or of seconds depending on the field). Fields that have only a current value are requested with =1 (or =true, which means the same). symbol is required. The snapshot is included from the Traders plan.

curl -H "X-API-KEY: $BYTNODE_API_KEY" \
  "https://api.bytnode.com/v1/snapshot?symbol=BTCUSDT\
&funding_rate=1\
&basis=1\
&fear_greed=1\
&cvd@1h=2"

With no field requested, the response returns an empty data and the catalogue of what your plan includes: available_fields (the fields without a timeframe), available_multi_tf_fields (requested as name@tf), timeframes and max_depth, the ceiling of each field. A client can build its requests from it without reading this page.

#The 48 fields

Thirty-seven fields are requested by their bare name (the discovery, /v1/snapshot?symbol=BTCUSDT, lists them). Each one has the name and the content of its route: a field whose route returns an object comes back as that object, requested with =1 (or =true) — a greater depth is a 422 that points to its /history route; the event fields (individual trades, liquidation events, per-second candles) are lists, up to the ceiling of the depth column.

#Multi-timeframe fields

Eleven fields exist per timeframe. They are requested with the @tf suffix, required, and the key comes back as is in data (data["cvd@1h"]). klines also takes 1w (timeframes_by_field in the catalogue). A @tf field is always a LIST, even at depth 1; a field without a timeframe is the OBJECT of its route (depth 1 only), except the event fields (trades, liquidations, seconds), which are lists.

1m5m15m30m1h4h1d

Requesting a multi-timeframe field without its suffix returns 422, and the reverse as well: a single-form field suffixed @1h is refused.

#The additive keys

{
  "status": "ok",
  "server_time": "2026-10-13T02:18:41.507Z",
  "data_type": "snapshot",
  "symbol": "USDCUSDT",
  "is_partial": false,
  "data": { "funding_rate": null, "options_summary": null, "heatmap_clusters": null },
  "unavailable": {
    "funding_rate": "not_applicable",
    "options_summary": "not_applicable",
    "heatmap_clusters": "not_applicable"
  }
}

{
  "status": "ok",
  "server_time": "2026-10-13T02:30:56.839Z",
  "data_type": "snapshot",
  "symbol": "BTCUSDT",
  "is_partial": false,
  "data": {
    "funding_rate": {"time": "2026-10-12T16:00:00.000Z", "period_end_at": "2026-10-13T00:00:00.000Z", "settled_at": "2026-10-13T00:00:00.005Z", "rate_pct": 0.0038949161538, "apr_pct": 4.26493318841, "is_closed": true},
    "basis": {"time": "2026-10-13T02:30:14.102Z", "basis_value": -33.9427339947, "basis_pct": -0.0410036905061, "futures_price": 82743.8733191, "spot_price": 82777.8160531}
  },
  "out_of_plan_fields": ["fear_greed", "btc_mvrv"]
}

#Errors

The history window of the plan applies to dated fields as it does to REST routes: klines@1h=1000 asks for a thousand hourly candles, which Traders (one week on 1h) refuses with an explicit 403 history_depth rather than returning 168 candles under the name of a thousand.

{
  "status": "error",
  "server_time": "2026-09-30T16:07:27.808Z",
  "error": {
    "code": "history_depth",
    "message": "History depth beyond your plan: 1000 hour(s) requested on 1h, your plan allows 7 day(s) (i.e. at most limit=168 on this timeframe, and no since_ms/until_ms bound beyond that window).",
    "param": "limit",
    "details": {
      "window_s": 604800,
      "earliest_ms": 1791273600000,
      "max_limit": 168,
      "timeframe": "1h"
    }
  }
}