Imaginez que vous souhaitiez suivre la façon dont le marché évalue un événement économique unique sur Kalshi, Polymarket et ForecastEx. Sur le papier, cela ressemble à un simple tableau de bord. En pratique, cela signifie trois API différentes, trois façons d'identifier le même marché et trois formats de réponse à concilier avant de pouvoir tracer un seul graphique.
Ce problème s'amplifie à chaque nouvelle plateforme. Les marchés de prédiction couvrent désormais des bourses américaines réglementées, des protocoles on-chain, des communautés d'argent fictif et des contrats événementiels de plateformes crypto établies, et aucun d'entre eux ne partage un modèle de données commun.
C'est le vide que FinFeedAPI est conçu pour combler. Son API Prediction Markets regroupe neuf bourses sous un schéma standardisé, afin que les développeurs puissent interroger les marchés, les transactions, les carnets d'ordres et l'historique de la même manière, quelle que soit la provenance des données.

Pour les développeurs, cette croissance s'accompagne d'une réalité désordonnée. Chaque plateforme expose sa propre API, ses propres identifiants de marché, ses propres conventions de nommage et sa propre idée de ce à quoi ressemble un « marché ». Vous voulez un tableau de bord qui suit le même événement sur trois plateformes ? Vous devez maintenant maintenir trois intégrations, trois modèles de données et trois ensembles de cas particuliers.
C'est exactement le problème que FinFeedAPI tente de résoudre.
Dans cette revue, je vais passer en revue ce que couvre l'API Prediction Markets de FinFeedAPI, les données que vous obtenez réellement, à quoi ressemblent les points de terminaison en pratique, combien cela coûte et où cela fait défaut, afin que vous puissiez décider si cela correspond à votre stack.
En bref
| Fournisseur | FinFeedAPI par API Bricks (également derrière CoinAPI) |
| Bourses couvertes | 9 plateformes de marchés de prédiction |
| Données | Marchés et métadonnées, transactions, cotations, carnets d'ordres, OHLCV, fichiers plats historiques |
| Accès | REST, JSON-RPC, serveur MCP hébergé, Flat Files (S3) |
| Mode | Données de marché en lecture seule, requête-réponse (pas de flux WebSocket) |
| Tarification | Crédits gratuits pour commencer, puis paiement à l'usage à partir de 1 $ pour 1 000 requêtes |
| Idéal pour | Tableaux de bord multi-bourses, recherche, backtesting, agents IA |
Qu'est-ce que FinFeedAPI ?

FinFeedAPI est un fournisseur de données financières créé par API Bricks, la même société derrière CoinAPI. En plus de ses API Stock, Currencies et SEC, il propose une API Prediction Markets qui vous donne un accès standardisé aux données de marché de neuf bourses de marchés de prédiction via une seule intégration.
L'idée est simple : au lieu d'apprendre neuf API, vous en apprenez une. Les identifiants de marché, les résultats, les horodatages et les structures de réponse suivent le même schéma, quelle que soit la bourse d'origine des données.
Quelques détails d'ingénierie m'ont marqué en parcourant la documentation :
- Modèle de données unifié sur toutes les bourses prises en charge
- Identifiants de marché standardisés qui incluent le résultat, par exemple
..._YESet..._NO - Horodatages ISO 8601 UTC sur chaque point de terminaison
- Précision numérique cohérente, jusqu'à 19 chiffres avec 9 décimales
- Quatre moyens d'accès : REST, JSON-RPC, un serveur MCP hébergé et Flat Files
Une chose à clarifier d'emblée : FinFeedAPI est une couche de données de marché en lecture seule. Il ne passe pas d'ordres. Si votre produit a besoin d'exécution, vous utiliserez toujours l'API native de chaque bourse pour cette partie.

Plateformes de marchés de prédiction prises en charge
FinFeedAPI couvre actuellement neuf plateformes, allant des bourses réglementées aux protocoles décentralisés, aux marchés de résultats on-chain et à une communauté d'argent fictif.
| Plateforme | Type | Ce qu'elle couvre |
|---|---|---|
| Polymarket | Décentralisé | Politique, économie, crypto, sports et événements mondiaux |
| Kalshi | Réglementé (CFTC) | Contrats événementiels américains sur les indicateurs économiques, les élections, la météo, les sports, etc. |
| ForecastEx | Réglementé (CFTC) | Contrats événementiels américains, y compris les résultats économiques et financiers |
| Gemini Prediction Markets | Réglementé | Contrats événementiels sur les sports, la crypto, l'économie, la politique et d'autres sujets |
| **Crypto.com Prediction Markets** | Réglementé | Contrats événementiels sur la plateforme de marchés de prédiction de Crypto.com |
| Myriad | Décentralisé | Crypto, actualités et autres résultats |
| Pascal | Décentralisé | Marchés de prédiction non dépositaires construits sur Solana |
| Hyperliquid Outcome Markets (HIP-4) | Marchés de résultats on-chain | Contrats événementiels binaires et multi-résultats sur l'infrastructure native d'Hyperliquid |
| Manifold Markets | Social, argent fictif | Marchés communautaires sur un large éventail de sujets |
Le mélange est ce qui rend cela intéressant. Comparer la façon dont une plateforme réglementée, une plateforme native de la crypto et une foule d'argent fictif évaluent le même événement, c'est là que la recherche multi-bourses devient précieuse. C'est aussi là qu'un schéma normalisé fait gagner le plus de temps.
À quelles données pouvez-vous accéder ?

C'est là que FinFeedAPI justifie son utilité. La plupart des outils de marchés de prédiction s'arrêtent au dernier prix. FinFeedAPI expose le marché entier, de la découverte à la profondeur du carnet d'ordres et à l'historique.
Tous les points de terminaison REST se trouvent sous https://api.prediction-markets.finfeedapi.com/v1.
| Jeu de données | Point de terminaison | Ce que vous obtenez |
|---|---|---|
| Bourses | GET /exchanges et /exchanges/{exchange_id} |
Plateformes prises en charge, identifiants de bourse, descriptions, sites web |
| Marchés actifs | GET /markets/{exchange_id}/active |
Une liste compacte des identifiants de marché actuellement actifs |
| Listes de marchés | GET /markets/{exchange_id}/history |
Enregistrements complets de marché avec pagination basée sur curseur : titres, descriptions, résultats, prix, statut |
| Marché unique | GET /markets/{exchange_id}/{market_id} |
Métadonnées pour un marché |
| Activité actuelle | GET /activity/{exchange_id}/{market_id}/current |
Dernière transaction plus dernière offre d'achat et de vente |
| Activité récente | GET /activity/{exchange_id}/{market_id}/latest |
Transactions récentes et mises à jour de cotations |
| Transactions et cotations historiques | GET /activity/{exchange_id}/{market_id}/history/trades et /history/quotes |
Enregistrements historiques servis à partir de fichiers plats |
| Carnet d'ordres actuel | GET /orderbook/{exchange_id}/{market_id}/current |
Offres d'achat et de vente pour un résultat de marché |
| Carnet d'ordres historique | GET /orderbook/{exchange_id}/{market_id}/history |
Événements bruts d'ordres à cours limité (ajouts, mises à jour, suppressions) pour la reconstruction du carnet |
| OHLCV | GET /ohlcv/periods, /ohlcv/{exchange_id}/{market_id}/history, /latest, /ohlcv/{exchange_id}/history |
Chandeliers avec ouverture, plus haut, plus bas, clôture, volume et nombre de transactions |
Quelques choses à savoir :
- La découverte se fait en deux étapes. Le point de terminaison
/activene renvoie que des identifiants, car il est dérivé des cotations et transactions récentes. Vous appelez/historyou le point de terminaison de marché unique pour obtenir tous les détails. - Les périodes OHLCV vont de quelques secondes à plusieurs années, et les chandeliers historiques sont renvoyés par ordre chronologique croissant, ce qui est idéal pour le backtesting.
- Les données historiques du carnet d'ordres sont au niveau de l'événement, pas seulement des instantanés. Cela ouvre la porte à la relecture de marché et à la recherche sur la liquidité.
- Les données de cycle de vie et de résolution couvrent les statuts ouvert, fermé, résolu et suspendu, avec des informations de résolution lorsque la bourse source les prend en charge.
Pour commencer : vos premières requêtes
L'intégration est rapide. Vous créez un compte gratuit, générez une clé API depuis la console et vous commencez avec des crédits gratuits.
Pour REST et JSON-RPC, vous transmettez la clé dans l'en-tête Authorization. La documentation accepte également X-APIKey, X-APIBricks-Key et X-CoinAPI-Key.
1. Lister les bourses prises en charge
Commencez ici pour obtenir les valeurs exactes de exchange_id que vous utiliserez partout ailleurs.
curl -X GET "<https://api.prediction-markets.finfeedapi.com/v1/exchanges>" \
-H "Authorization: YOUR_API_KEY"
2. Découvrir les marchés actifs
curl -X GET "<https://api.prediction-markets.finfeedapi.com/v1/markets/POLYMARKET/active?limit=10>" \
-H "Authorization: YOUR_API_KEY"
Cela renvoie une simple liste d'identifiants de marché, chacun avec son résultat intégré :
[
"WILL-TRUMP-SELL-10K-25K-GOLD-CARDS-IN-2025_YES",
"WILL-TRUMP-SELL-10K-25K-GOLD-CARDS-IN-2025_NO",
"NFL-PIT-CAR-2025-08-21-SPREAD-AWAY-5PT5_YES"
]
3. Obtenir la dernière transaction et cotation
curl -X GET \
"<https://api.prediction-markets.finfeedapi.com/v1/activity/POLYMARKET/WILL-TRUMP-SELL-10K-25K-GOLD-CARDS-IN-2025_YES/current>" \
-H "Authorization: YOUR_API_KEY"
La réponse vous donne la dernière transaction ainsi que la dernière offre d'achat et de vente pour ce résultat.
4. Récupérer l'historique OHLCV en Python
C'est l'appel que j'utiliserais en premier lors de la construction d'un graphique de probabilité ou d'un backtest.
import requests
API_KEY = "YOUR_API_KEY"
BASE = "<https://api.prediction-markets.finfeedapi.com/v1>"
headers = {"Authorization": API_KEY}
market_id = "WILL-TRUMP-SELL-10K-25K-GOLD-CARDS-IN-2025_YES"
resp = requests.get(
f"{BASE}/ohlcv/POLYMARKET/{market_id}/history",
headers=headers,
params={"period_id": "1DAY", "limit": 30},
)
resp.raise_for_status()
for candle in resp.json():
print(candle["time_period_start"], candle["price_close"], candle["volume_traded"])
Chaque chandelier inclut time_period_start, time_period_end, price_open, price_high, price_low, price_close, volume_traded et trades_count. Appelez /ohlcv/periods pour voir tous les period_id pris en charge.
5. Vérifier la profondeur du carnet d'ordres
curl -X GET \
"<https://api.prediction-markets.finfeedapi.com/v1/orderbook/POLYMARKET/WILL-TRUMP-SELL-10K-25K-GOLD-CARDS-IN-2025_YES/current>" \
-H "Authorization: YOUR_API_KEY"
L'instantané renvoie exchange_id, market_id, time_exchange, time_coinapi, ainsi que les tableaux bids et asks. Cela suffit pour calculer les écarts et le déséquilibre au sommet du carnet.
Si vous préférez ne pas écrire de HTTP brut, API Bricks publie des SDK officiels (Python, Node.js, Go, C# et autres) dans son dépôt GitHub SDK.
Au-delà de REST : MCP, JSON-RPC et Flat Files
Chaque interface expose les mêmes jeux de données standardisés. Vous choisissez celle qui correspond à votre architecture.
| Interface | En-tête d'authentification | Idéal pour |
|---|---|---|
| API REST | Authorization |
Tableaux de bord, analyses, applications de production |
| API JSON-RPC | Authorization |
Services qui préfèrent les appels de style RPC sur les mêmes données |
| Serveur MCP hébergé | X-APIKey |
Assistants IA, agents de codage, flux de recherche |
| Flat Files (S3) | Identifiants compatibles S3 | Historique en masse pour le backtesting et l'apprentissage automatique |
Le serveur MCP est la pièce maîtresse
De mon point de vue, c'est la partie la plus avant-gardiste du produit. Au lieu d'enseigner vos docs API à un agent, vous le pointez vers un point de terminaison MCP hébergé et il découvre les outils par lui-même.
La configuration se fait en quelques lignes dans Cursor, Claude Desktop ou tout client compatible MCP :
{
"mcpServers": {
"FinFeedAPI-Prediction-Markets": {
"url": "<https://api.prediction-markets.finfeedapi.com/mcp>",
"headers": {
"X-APIKey": "YOUR_API_KEY_HERE"
}
}
}
}
Le serveur expose actuellement des outils pour :
- Découverte de bourses :
exchanges_list,exchanges_get - Découverte de marchés :
markets_get_active,markets_get_history - Activité en direct :
activity_get_current,activity_get_latest - Transactions et cotations historiques :
activity_get_trades_history,activity_get_quotes_history - OHLCV :
ohlcv_list_periods,ohlcv_get_latest_market,ohlcv_get_history_market,ohlcv_get_history_exchange - Carnets d'ordres :
orderbook_get_current,orderbook_get_history
Cela signifie que vous pouvez demander à un agent quelque chose comme « trouvez les marchés Kalshi les plus actifs et montrez-moi comment leurs cotes ont évolué cette semaine » et il peut enchaîner les appels de découverte, d'activité et d'OHLCV tout seul.
Une remarque si vous avez configuré une ancienne connexion MCP FinFeedAPI : le point de terminaison est passé de /sse à /mcp, donc les anciennes configurations doivent être mises à jour.
Flat Files pour l'historique volumineux
Pour la recherche à grande échelle, extraire des années de données via des appels REST paginés est lent. Les Flat Files vous donnent en masse les transactions, cotations, carnets d'ordres et OHLCV via une API compatible S3, afin que vous puissiez utiliser les outils et SDK S3 que vous connaissez déjà.
Tarification

FinFeedAPI utilise une tarification à l'usage basée sur des crédits. Vous commencez avec des crédits gratuits, puis payez par requête.
En Paiement à l'usage, les 1 000 premières requêtes par jour coûtent 5 $ pour 1 000, et tout ce qui dépasse 1 000 par jour tombe à 1 $ pour 1 000. Les forfaits engagés réduisent ce tarif.
| Forfait | Mensuel | Tarif par crédit | Extras notables |
|---|---|---|---|
| Paiement à l'usage | Sans engagement | 1,00 $ | Support IA et e-mail, intégration en libre-service |
| Engagé 64 | 64 $ | 0,85 $ | Intégration assistée par IA |
| Engagé 256 | 256 $ | 0,75 $ | Intégration assistée par IA |
| Engagé 512 | 512 $ | 0,70 $ | Support Slack, canal Slack dédié |
| Engagé 1024 | 1 024 $ | 0,65 $ | SLA de disponibilité de 99,9 %, responsable de la réussite client, intégration humaine |
| Entreprise | Personnalisé | Personnalisé | SLA personnalisés, optimisations de latence, infrastructure dédiée |
Les forfaits engagés ne réduisent pas ce que vous consommez. Ils vous donnent plus de crédits pour le même budget, et une fois ces crédits épuisés, l'utilisation supplémentaire est facturée au tarif Paiement à l'usage. La facturation annuelle est également disponible.
Mon avis : pour les prototypes et la recherche, le Paiement à l'usage convient. Si vous interrogez de nombreux marchés toutes les quelques secondes, faites d'abord les calculs. FinFeedAPI publie des cas d'usage tarifaires pour les tableaux de bord, la surveillance des carnets d'ordres et les remplissages OHLCV qui facilitent grandement l'estimation.
Où FinFeedAPI fait défaut
Aucune API n'est parfaite, et une revue qui omet les compromis n'est pas très utile. Voici ce qu'il faut garder à l'esprit :
- Pas d'exécution d'ordres. C'est uniquement une couche de données. Les bots de trading ont toujours besoin des API natives des bourses pour passer des ordres.
- Pas de flux WebSocket pour les marchés de prédiction. Les données actuelles passent par des appels requête-réponse, donc « en direct » signifie interroger régulièrement. Pour les stratégies sensibles à la latence, c'est une vraie contrainte, et les interrogations fréquentes augmentent votre facture.
- Les 1 000 premières requêtes quotidiennes sont les plus chères. À 5 $ pour 1 000 contre 1 $ pour 1 000 ensuite, les très petits projets paient un taux effectif plus élevé que les projets actifs.
- Les données de résolution dépendent de la source. Les détails du cycle de vie et de résolution ne sont aussi complets que ce que chaque bourse expose.
- La normalisation est un compromis. Un schéma unifié est tout l'intérêt, mais si vous dépendez d'un champ unique à une plateforme, consultez les échantillons de données avant de vous engager.
Aucun de ces points n'est rédhibitoire pour l'analyse, la recherche ou les cas d'usage IA. Ils comptent surtout si vous construisez un système de trading à haute fréquence.
Qui devrait utiliser FinFeedAPI ?
Points forts
- Neuf plateformes de marchés de prédiction derrière un seul schéma
- Cycle de vie complet du marché : découverte, transactions, cotations, carnets d'ordres, OHLCV, historique
- Données historiques du carnet d'ordres au niveau de l'événement pour la relecture
- Serveur MCP hébergé qui fonctionne avec Cursor et Claude Desktop
- Flat Files en masse pour la recherche et l'apprentissage automatique
- Tarification à l'usage avec des crédits gratuits pour commencer
Idéal pour
- Tableaux de bord multi-bourses qui comparent les cotes entre les plateformes
- Chercheurs quantitatifs et analystes qui backtestent des stratégies de marchés de prédiction
- Équipes de prévision et de ML qui ont besoin d'OHLCV historiques propres
- Analyses de liquidité basées sur la profondeur du carnet d'ordres et les écarts
- Équipes IA qui construisent des agents raisonnant sur des événements du monde réel
- Recherche académique et économique sur la façon dont les foules évaluent les résultats
Probablement pas pour
- Les bots qui ont besoin de passer des ordres
- Les stratégies qui ont besoin d'un flux push inférieur à la seconde
Réflexions finales

Les marchés de prédiction croissent plus vite que la plupart des équipes ne peuvent les intégrer. Chaque nouvelle plateforme apporte de nouveaux identifiants, de nouveaux formats et de nouveaux travaux de maintenance.
FinFeedAPI n'essaie pas d'être une bourse. Il se concentre sur une tâche : transformer neuf plateformes fragmentées en une couche de données cohérente. Marchés, transactions, cotations, carnets d'ordres, OHLCV et historique profond reviennent tous sous la même forme, via REST, JSON-RPC, MCP ou Flat Files.
Partez du principe qu'il est en lecture seule et en requête-réponse, et il convient à un large éventail de produits, des tableaux de bord de prévision aux agents de recherche IA.
Neuf plateformes. Un schéma. Une clé API. Moins de plomberie, plus de construction.
Site web : finfeedapi.com/products/prediction-markets-api
Documentation API : Documentation de l'API REST des marchés de prédiction
Les marchés de prédiction croissent plus vite que la plupart des équipes ne peuvent les intégrer. Chaque nouvelle plateforme apporte de nouveaux identifiants, de nouveaux formats et de nouveaux travaux de maintenance.
FinFeedAPI n'essaie pas d'être une bourse. Il se concentre sur une tâche : transformer neuf plateformes fragmentées en une couche de données cohérente. Marchés, transactions, cotations, carnets d'ordres, OHLCV et historique profond reviennent tous sous la même forme, via REST, JSON-RPC, MCP ou Flat Files.
Partez du principe qu'il est en lecture seule et en requête-réponse, et il convient à un large éventail de produits, des tableaux de bord de prévision aux agents de recherche IA.
Neuf plateformes. Un schéma. Une clé API. Moins de plomberie, plus de construction.
Site web : finfeedapi.com/products/prediction-markets-api
Documentation API : Documentation de l'API REST des marchés de prédiction
