period, market, line) et porte un line_id entier stable.
Types de marché
Pour les marchés 2‑way (spread/totals),
odds0 est null.
units — l’unité de la ligne (tennis : jeux vs sets)
Certains sports cotent le même marché dans deux unités différentes. Au tennis, un spread peut être un
handicap de sets (ligne ±1.5) ou un handicap de jeux (ligne -4.5, +5.5…), et un totals peut porter
sur les sets (2.5) ou sur les jeux (21.5). Le champ units lève l’ambiguïté :
Les totaux par joueur (
home_totals / away_totals) du tennis sont toujours en jeux (units = "Games").
Le champ est présent sur /api/odds, /api/opening, /api/closing, /api/history et les flux temps réel.
Périodes
period = 0 = match complet. Les autres périodes dépendent du sport (1 = 1re mi‑temps / set, etc.). Récupérez le catalogue via /api/periods.
Lignes principales vs alt‑lines
Par défaut,/api/odds renvoie toutes les lignes (y compris les alternatives). Ajoutez main_lines_only=1 pour ne garder que la ligne principale de chaque marché (alt_line_id nul).
max_win
max_win = mise maximale acceptée (limite Pinnacle) sur la ligne, indicateur de liquidité.
Historique : max_win et status sont des points de série
/api/history renvoie un point par changement réel, jamais de valeur répétée. Un point est créé
dès que l’un de ces champs bouge :
Un
max_win qui monte pendant que la cote ne bouge pas est un signal de confiance du book ; un
max_win qui s’effondre précède souvent une suspension. La série étant déjà dédoublonnée côté API,
elle se trace telle quelle.
Isoler un seul pari
Sans filtre,/api/history renvoie la timeline de toutes les lignes du match. Sur un match de
basket avec ses alt‑lines, cela dépasse couramment 24 000 points répartis sur plus de 400 paris —
alors que vous n’en voulez qu’une courbe.
Deux façons de désigner le pari, selon ce que vous avez déjà sous la main :
Les filtres valent aussi pour
opening et closing : vous obtenez l’ouverture et la clôture du
pari demandé, pas celles des 414 autres.
Effet mesuré sur un match réel :
Les trois niveaux de statut
Pinnacle publie un statut à trois échelles différentes, chacune avec son propre vocabulaire. Les confondre est l’erreur la plus fréquente : un marché fermé ne veut pas dire un match terminé, et une mi-temps réglée ne ferme pas les paris sur le match entier.Niveau ligne
Le statut appartient à la ligne, pas au marché. Sur un même(event_id, period, market), les
paliers de l’échelle divergent — Pinnacle ferme un total précis en gardant les voisins ouverts :
status, un entier de parité BIC (1 = ouvert, 2 = tout le reste),
et status_raw, le mot tel que Pinnacle l’envoie.
status_raw n’est renseigné que sur les cotes courantes. L’historique (/api/history,
full_history=1) ne conserve que l’entier : le mot d’origine n’y est pas stocké, le champ y vaut
null.Niveau période
/api/fixtures expose periods, une liste {period, status, cutoff}. C’est là que Pinnacle
déclare qu’une mi-temps est close, indépendamment des lignes et de l’état du match :
Le règlement d’une période est un événement à part entière sur le flux : une mi-temps qui
bascule en
settled déclenche une trame event: update, sans qu’aucune cote n’ait besoin de
bouger.Distinguer une suspension d’une fermeture définitive
Aucun champ ne le dit — le temps le dit :- suspension — la ligne reste publiée, passe en
closed, conserve sa dernière cote connue (nous ne l’effaçons pas, comme l’interface Pinnacle qui grise le prix), puis repasseopen; - fermeture définitive — la ligne cesse d’être republiée : son
cutoffpasse, elle quitte/api/odds, et une suppression est annoncée sur le flux (voir Prématch & live).