FinFeedAPI Review: Multi-Exchange-Daten-API für Prognosemärkte

Stellen Sie sich vor, Sie möchten verfolgen, wie der Markt ein einzelnes wirtschaftliches Ereignis über Kalshi, Polymarket und ForecastEx hinweg bepreist. Auf dem Papier klingt das nach einem einfachen Dashboard. In der Praxis bedeutet es drei verschiedene APIs, drei Arten, denselben Markt zu identifizieren, und drei Antwortformate, die abgeglichen werden müssen, bevor Sie ein einziges Diagramm zeichnen können.

Dieses Problem wächst mit jedem neuen Handelsplatz. Prognosemärkte erstrecken sich heute über regulierte US-Börsen, On-Chain-Protokolle, Spielgeld-Communitys und Event-Kontrakte etablierter Krypto-Plattformen – und keiner davon teilt ein gemeinsames Datenmodell.

Genau diese Lücke soll FinFeedAPI schließen. Seine Prediction Markets API bringt neun Börsen unter ein standardisiertes Schema, sodass Entwickler Märkte, Trades, Orderbücher und Historien auf dieselbe Weise abfragen können, unabhängig davon, woher die Daten stammen.

Für Entwickler bringt dieses Wachstum eine unangenehme Wahrheit mit sich. Jeder Handelsplatz bietet seine eigene API, eigene Markt-IDs, eigene Namenskonventionen und eine eigene Vorstellung davon, wie ein „Markt“ überhaupt aussieht. Sie wollen ein Dashboard, das dasselbe Ereignis über drei Plattformen hinweg verfolgt? Dann pflegen Sie jetzt drei Integrationen, drei Datenmodelle und drei Sätze von Sonderfällen.

Genau dieses Problem versucht FinFeedAPI zu lösen.

In diesem Review gehe ich durch, was die Prediction Markets API von FinFeedAPI abdeckt, welche Daten Sie tatsächlich erhalten, wie die Endpunkte in der Praxis aussehen, was sie kostet und wo sie Schwächen hat – damit Sie entscheiden können, ob sie zu Ihrem Stack passt.

TL;DR

Was ist FinFeedAPI?

FinFeedAPI ist ein Finanzdatenanbieter, entwickelt von API Bricks, demselben Unternehmen hinter CoinAPI. Neben seinen Stock-, Currencies- und SEC-APIs bietet es eine Prediction Markets API, die Ihnen standardisierten Zugriff auf Marktdaten von neun Prognosemarkt-Börsen über eine einzige Integration bietet.

Die Idee ist einfach: Statt neun APIs zu lernen, lernen Sie eine. Markt-IDs, Outcomes, Zeitstempel und Antwortstrukturen folgen demselben Schema, egal von welcher Börse die Daten stammen.

Ein paar technische Details sind mir beim Durchgehen der Dokumentation aufgefallen:

• Einheitliches Datenmodell über alle unterstützten Börsen hinweg
• Standardisierte Markt-IDs, die das Outcome enthalten, zum Beispiel ..._YES und ..._NO
• ISO-8601-UTC-Zeitstempel bei jedem Endpunkt
• Konsistente numerische Präzision, bis zu 19 Stellen mit 9 Dezimalstellen
• Vier Zugangswege: REST, JSON-RPC, ein gehosteter MCP-Server und Flat Files

Eines sollten wir gleich vorweg klarstellen: FinFeedAPI ist eine schreibgeschützte Marktdatenschicht. Es platziert keine Orders. Wenn Ihr Produkt die Order-Ausführung benötigt, verwenden Sie dafür weiterhin die native API der jeweiligen Börse.

Unterstützte Prognosemarkt-Plattformen

FinFeedAPI deckt derzeit neun Handelsplätze ab, von regulierten Börsen über dezentrale Protokolle und On-Chain-Outcome-Märkte bis hin zu einer Spielgeld-Community.

Die Mischung macht das Ganze interessant. Der Vergleich, wie ein regulierter Handelsplatz, ein krypto-nativer Handelsplatz und eine Spielgeld-Community dasselbe Ereignis bepreisen, ist der Punkt, an dem börsenübergreifende Research wertvoll wird. Und genau dort spart ein normalisiertes Schema die meiste Zeit.

Auf welche Daten können Sie zugreifen?

Hier spielt FinFeedAPI seine Stärken aus. Die meisten Prognosemarkt-Tools enden beim letzten Preis. FinFeedAPI legt den gesamten Markt offen – von der Marktentdeckung bis zur Orderbuch-Tiefe und Historie.

Alle REST-Endpunkte liegen unter https://api.prediction-markets.finfeedapi.com/v1.

Ein paar Dinge, die man wissen sollte:

• Die Marktentdeckung erfolgt in zwei Schritten. Der Endpunkt /active liefert nur IDs zurück, da er aus aktuellen Quotes und Trades abgeleitet wird. Für vollständige Details rufen Sie /history oder den Endpunkt für einen einzelnen Markt auf.
• OHLCV-Perioden reichen von Sekunden bis zu Jahren, und historische Candles kommen in aufsteigender Zeitreihenfolge zurück – genau das, was Sie für Backtesting wollen.
• Historische Orderbuch-Daten liegen auf Event-Ebene vor, nicht nur als Snapshots. Das öffnet die Tür zu Markt-Replay und Liquiditäts-Research.
• Lifecycle- und Resolution-Daten decken die Status offen, geschlossen, aufgelöst und ausgesetzt ab, mit Auflösungsinformationen, sofern die Quellbörse diese unterstützt.

Erste Schritte: Ihre ersten Anfragen

Das Onboarding geht schnell. Sie erstellen ein kostenloses Konto, generieren in der Konsole einen API-Schlüssel und starten mit kostenlosen Credits.

Bei REST und JSON-RPC übergeben Sie den Schlüssel im Header Authorization. Die Dokumentation akzeptiert außerdem X-APIKey, X-APIBricks-Key und X-CoinAPI-Key.

1. Unterstützte Börsen auflisten

Beginnen Sie hier, um die genauen exchange_id-Werte zu erhalten, die Sie überall sonst verwenden werden.

curl -X GET "<https://api.prediction-markets.finfeedapi.com/v1/exchanges>" \
  -H "Authorization: YOUR_API_KEY"

2. Aktive Märkte entdecken

curl -X GET "<https://api.prediction-markets.finfeedapi.com/v1/markets/POLYMARKET/active?limit=10>" \
  -H "Authorization: YOUR_API_KEY"

Dies gibt eine einfache Liste von Markt-IDs zurück, jede mit dem bereits enthaltenen Outcome:

[
  "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. Den letzten Trade und Quote abrufen

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"

Die Antwort liefert den letzten Trade zusammen mit dem aktuellsten Bid und Ask für dieses Outcome.

4. Historische OHLCV-Daten in Python abrufen

Das ist der Aufruf, zu dem ich zuerst greifen würde, wenn ich ein Wahrscheinlichkeitsdiagramm oder einen Backtest erstelle.

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"])

Jede Candle enthält time_period_start, time_period_end, price_open, price_high, price_low, price_close, volume_traded und trades_count. Rufen Sie /ohlcv/periods auf, um alle unterstützten period_id-Werte zu sehen.

5. Orderbuch-Tiefe prüfen

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"

Der Snapshot liefert exchange_id, market_id, time_exchange, time_coinapi sowie bids- und asks-Arrays. Das reicht aus, um Spreads und Top-of-Book-Ungleichgewicht zu berechnen.

Wenn Sie kein rohes HTTP schreiben möchten: API Bricks veröffentlicht offizielle SDKs (Python, Node.js, Go, C# und weitere) in seinem GitHub-SDK-Repo.

Jenseits von REST: MCP, JSON-RPC und Flat Files

Jede Schnittstelle stellt dieselben standardisierten Datensätze bereit. Sie wählen diejenige, die zu Ihrer Architektur passt.

Der MCP-Server sticht hervor

Aus meiner Sicht ist dies der zukunftsweisendste Teil des Produkts. Statt einem Agenten Ihre API-Dokumentation beizubringen, verweisen Sie ihn auf einen gehosteten MCP-Endpunkt, und er entdeckt die Tools selbst.

Die Einrichtung besteht aus wenigen Konfigurationszeilen in Cursor, Claude Desktop oder einem beliebigen MCP-fähigen Client:

{
  "mcpServers": {
    "FinFeedAPI-Prediction-Markets": {
      "url": "<https://api.prediction-markets.finfeedapi.com/mcp>",
      "headers": {
        "X-APIKey": "YOUR_API_KEY_HERE"
      }
    }
  }
}

Der Server stellt derzeit Tools bereit für:

• Börsen-Entdeckung: exchanges_list, exchanges_get
• Markt-Entdeckung: markets_get_active, markets_get_history
• Live-Aktivität: activity_get_current, activity_get_latest
• Historische Trades und Quotes: activity_get_trades_history, activity_get_quotes_history
• OHLCV: ohlcv_list_periods, ohlcv_get_latest_market, ohlcv_get_history_market, ohlcv_get_history_exchange
• Orderbücher: orderbook_get_current, orderbook_get_history

Das bedeutet, Sie können einen Agenten etwa fragen: „Finde die aktivsten Kalshi-Märkte und zeig mir, wie sich ihre Quoten diese Woche entwickelt haben“ – und er kann Entdeckungs-, Aktivitäts- und OHLCV-Aufrufe selbstständig verketten.

Ein Hinweis, falls Sie eine ältere FinFeedAPI-MCP-Verbindung eingerichtet haben: Der Endpunkt wurde von /sse auf /mcp verschoben, ältere Konfigurationen müssen also aktualisiert werden.

Flat Files für umfangreiche Historien

Für Research in großem Umfang ist das Abrufen von Jahren an Daten über paginierte REST-Aufrufe langsam. Flat Files liefern Ihnen Trades, Quotes, Orderbücher und OHLCV in großen Mengen über eine S3-kompatible API, sodass Sie die S3-Tools und SDKs nutzen können, die Sie bereits kennen.

Preisgestaltung

FinFeedAPI verwendet ein credit-basiertes, nutzungsabhängiges Preismodell. Sie starten mit kostenlosen Credits und zahlen dann pro Anfrage.

Bei Pay As You Go kosten die ersten 1.000 Anfragen pro Tag 5 $ pro 1.000, und alles über 1.000 pro Tag sinkt auf 1 $ pro 1.000. Committed-Pläne senken diesen Satz.

Committed-Pläne reduzieren nicht Ihren Verbrauch. Sie erhalten mehr Credits für denselben Betrag, und sobald diese Credits aufgebraucht sind, wird die zusätzliche Nutzung zum Pay-As-You-Go-Satz abgerechnet. Eine jährliche Abrechnung ist ebenfalls verfügbar.

Meine Einschätzung: Für Prototypen und Research ist Pay As You Go in Ordnung. Wenn Sie alle paar Sekunden viele Märkte abfragen, rechnen Sie zuerst nach. FinFeedAPI veröffentlicht Preisbeispiele für Dashboards, Orderbuch-Monitoring und OHLCV-Backfills, die die Schätzung deutlich einfacher machen.

Wo FinFeedAPI Schwächen hat

Keine API ist perfekt, und ein Review, das die Kompromisse auslässt, ist wenig nützlich. Das sollten Sie im Hinterkopf behalten:

• Keine Order-Ausführung. Es ist ausschließlich eine Datenschicht. Trading-Bots benötigen weiterhin die nativen Börsen-APIs, um Orders zu platzieren.
• Kein WebSocket-Stream für Prognosemärkte. Aktuelle Daten kommen über Request-Response-Aufrufe, „live“ bedeutet also Polling. Für latenzempfindliche Strategien ist das eine echte Einschränkung, und häufiges Polling erhöht Ihre Rechnung.
• Die ersten 1.000 Anfragen pro Tag sind am teuersten. Bei 5 $ pro 1.000 gegenüber 1 $ pro 1.000 danach zahlen sehr kleine Projekte einen höheren effektiven Satz als stark genutzte.
• Auflösungsdaten hängen von der Quelle ab. Lifecycle- und Auflösungsdetails sind nur so vollständig, wie es die jeweilige Börse offenlegt.
• Die Normalisierung ist ein Kompromiss. Ein einheitliches Schema ist der ganze Sinn der Sache, aber wenn Sie auf ein Feld angewiesen sind, das nur ein Handelsplatz bietet, prüfen Sie die Datenbeispiele, bevor Sie sich festlegen.

Nichts davon ist ein Ausschlusskriterium für Analytics, Research oder KI-Anwendungsfälle. Am wichtigsten sind sie, wenn Sie ein Hochfrequenz-Handelssystem bauen.

Für wen ist FinFeedAPI geeignet?

Stärken

• Neun Prognosemarkt-Handelsplätze hinter einem Schema
• Vollständiger Marktlebenszyklus: Entdeckung, Trades, Quotes, Orderbücher, OHLCV, Historie
• Historische Orderbuch-Daten auf Event-Ebene für Replay
• Gehosteter MCP-Server, der mit Cursor und Claude Desktop funktioniert
• Flat Files in großen Mengen für Research und Machine Learning
• Nutzungsbasierte Preisgestaltung mit kostenlosen Start-Credits

Am besten geeignet für

• Multi-Börsen-Dashboards, die Quoten über Handelsplätze hinweg vergleichen
• Quant-Researcher und Analysten, die Prognosemarkt-Strategien backtesten
• Forecasting- und ML-Teams, die saubere historische OHLCV-Daten benötigen
• Liquiditätsanalysen auf Basis von Orderbuch-Tiefe und Spreads
• KI-Teams, die Agenten entwickeln, die über reale Ereignisse schlussfolgern
• Akademische und wirtschaftswissenschaftliche Forschung darüber, wie Crowds Outcomes bepreisen

Wahrscheinlich nicht geeignet für

• Bots, die Orders platzieren müssen
• Strategien, die einen push-basierten Stream im Subsekundenbereich benötigen

Fazit

Prognosemärkte wachsen schneller, als die meisten Teams sie integrieren können. Jeder neue Handelsplatz bringt neue Identifikatoren, neue Formate und neuen Wartungsaufwand.

FinFeedAPI versucht nicht, eine Börse zu sein. Es konzentriert sich auf eine Aufgabe: neun fragmentierte Handelsplätze in eine konsistente Datenschicht zu verwandeln. Märkte, Trades, Quotes, Orderbücher, OHLCV und tiefe Historien kommen alle in derselben Form zurück – über REST, JSON-RPC, MCP oder Flat Files.

Wenn Sie wissen, dass es schreibgeschützt und Request-Response-basiert ist, passt es zu einer breiten Palette von Produkten, von Forecasting-Dashboards bis zu KI-Research-Agenten.

Neun Handelsplätze. Ein Schema. Ein API-Schlüssel. Weniger Verkabelung, mehr Bauen.

Website: finfeedapi.com/products/prediction-markets-api

API-Dokumentation: Dokumentation der Prediction Markets REST API

Prognosemärkte wachsen schneller, als die meisten Teams sie integrieren können. Jeder neue Handelsplatz bringt neue Identifikatoren, neue Formate und neuen Wartungsaufwand.

FinFeedAPI versucht nicht, eine Börse zu sein. Es konzentriert sich auf eine Aufgabe: neun fragmentierte Handelsplätze in eine konsistente Datenschicht zu verwandeln. Märkte, Trades, Quotes, Orderbücher, OHLCV und tiefe Historien kommen alle in derselben Form zurück – über REST, JSON-RPC, MCP oder Flat Files.

Wenn Sie wissen, dass es schreibgeschützt und Request-Response-basiert ist, passt es zu einer breiten Palette von Produkten, von Forecasting-Dashboards bis zu KI-Research-Agenten.

Neun Handelsplätze. Ein Schema. Ein API-Schlüssel. Weniger Verkabelung, mehr Bauen.

Website: finfeedapi.com/products/prediction-markets-api

API-Dokumentation: Dokumentation der Prediction Markets REST API