API Polymarket : récupérer les événements publics

Découvrir les événements publics sans clé

Sur Polymarket, l'API Gamma expose des points d'entrée de découverte en lecture seule qui ne demandent aucune authentification. Tu peux lister les événements actifs et ouverts avec une simple requête GET, en passant des paramètres comme active=true, closed=false, limit et after_cursor. La réponse contient un tableau events et, s'il reste des pages, un next_cursor à réutiliser dans l'appel suivant. Cette découverte publique produit une observation, pas un droit de négocier : aucun ordre ne peut être envoyé par ce chemin.

Ces points d'entrée renvoient un instantané limité en lecture seule. L'absence d'un champ ne signifie pas que sa valeur est zéro : un volume ou une liquidité absente du JSON reste inconnue tant que tu ne l'as pas confirmée par un autre appel.

Event ID, market ID et token ID : ne pas confondre

Un événement rassemble souvent plusieurs marchés. Le champ id renvoyé par events/keyset est l'identifiant de l'événement. Il ne correspond ni à l'identifiant de marché, ni à l'identifiant de condition, ni à l'outcome token ID utilisé pour le trading. Vérifie le type d’identifiant attendu par chaque point d’entrée avant de construire ta requête.

Pour relier un événement à ses marchés, utilise les identifiants documentés dans les détails de marché plutôt qu'une déduction à partir du slug. Les tableaux sérialisés de market details, comme outcomes ou clobTokenIds, demandent souvent un parsing supplémentaire avant de devenir exploitables.

Exemple exécuté : 2 événements observés

Le script ci-dessous a été exécuté avec la bibliothèque standard Python, sans paquet externe et sans clé de trading. Il appelle events/keyset avec active=true, closed=false et limit=2, puis imprime l'horodatage d'observation, l'id, le slug et le titre des 2 premiers événements, ainsi qu'un booléen indiquant la présence d'un next_cursor. Il s'agit d'une illustration technique, pas d'une étude empirique.

La sortie a été capturée le 10 octobre 2026 à 12:18:52 UTC. La portée est volontairement étroite : lecture seule, 2 enregistrements de métadonnées d'événements publics, aucun ordre et aucun compte. Les 2 événements renvoyés étaient kraken-ipo-in-2025 (id 16183) et macron-out-in-2025 (id 16263). Le champ has_next_page valait true, ce qui veut dire qu'il faut paginer pour voir la suite.

Paginer avec le curseur jusqu'à épuisement

events/keyset ne fonctionne pas par numéro de page. Quand next_cursor est présent dans la réponse, tu le passes au paramètre after_cursor de la requête suivante pour obtenir le lot suivant. Tu répètes l'opération tant que le curseur existe. Ne conclus pas que la liste complète tient dans la première page : tu n'as vu qu'une page.

Quand next_cursor est absent, cela marque la fin normale du résultat de pagination courant. Traite cette absence comme une fin, pas comme une erreur. Conserve l'horodatage de chaque page si tu veux reconstituer l'ordre de collecte.

Lire closed, acceptingOrders et la date des prix

2 champs distincts méritent un contrôle séparé : closed signale que le marché est fermé, acceptingOrders indique s'il accepte encore des ordres. Un marché peut être encore ouvert tout en ayant cessé d'accepter des ordres. Les 2 champs doivent être vérifiés indépendamment, car ils ne décrivent pas la même propriété. Pour les prix, outcomePrices est une observation horodatée : note la date à laquelle tu l'as lue, sinon tu confonds une variation réelle avec un simple décalage de collecte. Volume et liquidité mesurent 2 choses différentes. Une valeur périmée ou absente reste inconnue.

Journaliser ces champs avec l'heure de la requête évite de présenter une observation ancienne comme un état courant. C'est une discipline peu coûteuse qui améliore ensuite les analyses plus fines.

Le code exécuté

Le bloc ci-dessous reproduit le code exécuté tel quel. Il utilise urllib.request et json de la bibliothèque standard, avec un User-Agent explicite et un timeout de 20 secondes. Aucun secret n'y figure : la découverte publique n'en a pas besoin. L'authentification pour soumettre des ordres sort du périmètre de ce guide.

import json
from datetime import datetime, timezone
from urllib.request import Request, urlopen

url = "https://gamma-api.polymarket.com/events/keyset?active=true&closed=false&limit=2"
request = Request(url, headers={"User-Agent": "PolyZenoResearch/1.0"})
with urlopen(request, timeout=20) as response:
    data = json.load(response)
print(json.dumps({
    "observed_at": datetime.now(timezone.utc).isoformat(),
    "events": [{"id": e["id"], "slug": e["slug"], "title": e["title"]}
               for e in data["events"]],
    "has_next_page": bool(data.get("next_cursor"))
}, ensure_ascii=False, indent=2))

Ce que cet appel ne dit pas

Faire tourner ce script n'envoie aucun ordre et ne demande aucune clé de trading : tu restes en lecture seule. Les cas perdants sont ailleurs : une requête construite avec un type d’identifiant inadapté, un next_cursor non suivi qui tronque silencieusement la liste, ou un prix observé la veille utilisé comme s'il était actuel. Ces erreurs ne se voient pas dans un tableau de bord qui n'affiche pas sa date de collecte.

Pour aller plus loin, oriente ton outil selon ton besoin réel. Si tu automatises des requêtes répétées, encadre-les par des limites et des journaux d'exécution. Si tu veux comprendre les usages automatisés sur la plateforme, lis le guide sur les bots de trading. Si ta question porte sur la profondeur des carnets, regarde la liquidité. Pour le contexte général, reviens à la présentation de Polymarket.