Conventions

#Symboles

Vingt-deux actifs sont suivis : vingt perpétuels USDT-M et deux stablecoins, ces derniers en spot uniquement. La liste vivante est servie par /v1/symbols, et c’est elle qui fait foi.

#Unités de temps

Sur les routes par intervalles, sept valeurs :

1m5m15m30m1h4h1d

Les indicateurs techniques en acceptent une huitième, la semaine, parce qu’ils sont calculés directement sur les bougies :

1m5m15m30m1h4h1d1w

Deux exceptions à retenir :

• Le ratio long/short refuse 1m : aucune place ne publie de ratio de compte global à cette unité de temps.
• Les instruments macro intrajournaliers refusent 30m et cinq d’entre eux ne sont servis qu’en 1d. Le catalogue de la famille dit lesquels.

Une valeur hors liste renvoie 422 avec les valeurs acceptées, jamais un repli silencieux sur une autre unité de temps.

#Agrégation multi-places

Aucune réponse ne nomme sa place de marché. Les métriques multi-places arrivent déjà fusionnées : c’est le contrat de la plateforme, et la raison pour laquelle plusieurs intégrations deviennent une seule. Trois règles de fusion, selon la nature de la grandeur :

Une seule exception dans toute l’API : /v1/spread/interexchange nomme les places, un écart n’ayant pas de sens sans elles. Partout ailleurs le paramètre exchange n’existe pas : le passer renvoie 422.

#Bougies closes et période en cours

Six familles servent des données découpées en fenêtres : les bougies de transactions, le VWAP par fenêtre, le CVD, le carnet d’ordres agrégé, les écarts entre places et le ratio long/short. Sur celles-ci, chaque ligne porte un booléen is_closed, que vous l’ayez demandé ou non.

Par défaut, seules les fenêtres closes sont servies. Pour voir la période en cours, ajoutez ?live=1 :

# The latest CLOSED hourly candle: its value will not move again.
curl -H "X-API-KEY: $BYTNODE_KEY" \
  "https://api.bytnode.com/v1/cvd?symbol=BTCUSDT&timeframe=1h"

# The candle IN PROGRESS: provisional, flagged is_closed: false.
curl -H "X-API-KEY: $BYTNODE_KEY" \
  "https://api.bytnode.com/v1/cvd?symbol=BTCUSDT&timeframe=1h&live=1"

#Couverture des sources

Comme la place n’est jamais nommée, un funding calculé sur deux places a la même forme qu’un funding calculé sur six. Deux mécanismes restituent l’information :

• venue_count, ligne par ligne : le nombre réel pour la fenêtre concernée. Il varie d’une fenêtre à l’autre, il ne peut donc pas être un attribut global. Le funding le nomme exchange_count, pour des raisons historiques.
• la clé coverage du snapshot, pour ce qui est constant sur toutes les lignes : combien de places étaient attendues, et l’effet d’une absence.

{
  "coverage": {
    "oi_history": {
      "status": "available",
      "effect": "additive",
      "count_field": "venue_count",
      "venues_expected": 6
    },
    "cvd@1h": { "status": "unavailable", "reason": "pre_aggregated" }
  }
}

#Horodatages et ordre

• Les horodatages des données sont en ISO 8601, en UTC : 2026-08-29T11:38:00+00:00. La clé bucket désigne le début de la fenêtre, jamais sa fin.
• Les bornes de requête (since_ms et until_ms) sont en millisecondes depuis l’époque Unix. Une borne négative, ou un since_ms supérieur à until_ms, renvoie 422.
• Les tableaux de valeurs (la série d’un indicateur, la série interne d’un CVD) vont du plus ancien au plus récent.
• Les listes d’historique sont renvoyées du plus récent au plus ancien. La ligne la plus fraîche vient en premier.
• La journée commence à minuit UTC : c’est la remise à zéro du VWAP intrajournalier, et l’alignement des séries quotidiennes.