Öffentliche / Bot-API

Sende bei jeder Anfrage Authorization: Bearer kirichess_pat_…. Es gibt genau zwei Geltungsbereiche. Ein Token trägt nie Admin- oder 2FA-Ansprüche, auch wenn das Konto sie hat. Bis zu 10 Token können gleichzeitig aktiv sein. Ein Token gilt 90 Tage, sofern du keine andere Laufzeit zwischen 1 und 365 Tagen wählst, und du kannst es vorher über die Karte API-Token auf deiner Profilseite widerrufen.

Nach kirichess_pat_ folgen 43 Zeichen aus dem URL-sicheren Base64-Alphabet (A–Z, a–z, 0–9, Bindestrich, Unterstrich) und danach 6 Prüfsummenzeichen. Die Prüfsumme ist die CRC-32 (IEEE) dieser 43 Zeichen, geschrieben als 6 Base62-Ziffern im Alphabet 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz, links mit Nullen aufgefüllt. Ein Secret-Scanner kann eine Zeichenkette, die diese Prüfung nicht besteht, verwerfen, ohne diesen Server aufzurufen.

• read, Identität, deine Partien, beendete Wiedergaben, deine offenen Herausforderungen, Wertungen des Bot-Pools, Bot-Suchanfragen.
• play, ungewertete Partien und Herausforderungen erstellen, ziehen und aufgeben, und über den Hub der Partiesuche im Bot-Pool beitreten. Play schließt read bei der Ausstellung ein.

Deine Engine läuft in dem Prozess, der diese API aufruft. Browser-Ursprünge außer dieser Website bleiben blockiert; CORS wird für diese API nicht geöffnet.

curl https://api.kirichess.com/api/v1/account \
  -H "Authorization: Bearer $KIRICHESS_API_TOKEN"

POST /api/v1/games legt nur eine Solo-Partie an, beide Plätze bist du, um die Engine von Anfang bis Ende zu üben. Eine opponentId, die auf jemand anderen zeigt, wird abgelehnt: gepaartes Spiel läuft immer über POST /api/v1/challenges oder den Bot-Pool. Gewertete Messung ist freiwillig: Verbinde dich mit demselben Token zum Partie-Hub und rufe JoinQueue mit einem offiziellen Preset auf (bounty1, burn1, steal1, steal2, burn2, steal3). Das wird auf bot:{preset} abgebildet und vermischt sich nie mit dem menschlichen Glicko.

Der Bot-Pool ist eine Höflichkeit gegenüber ehrlichen Bot-Autoren, keine technische Schranke: Ein Skript, das sich mit dem Passwort eines Kontos anmeldet, ist an der Warteschlange nicht von einem Browser zu unterscheiden und landet im menschlichen Pool. Im menschlichen Pool von einem Skript aus zu spielen verstößt gegen die Regeln, unabhängig davon, mit welchen Zugangsdaten es sich authentifiziert.

curl -X POST https://api.kirichess.com/api/v1/games \
  -H "Authorization: Bearer $KIRICHESS_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"preset":"bounty1","opponentId":null,"rated":false}'

Verbinde dich mit wss://api.kirichess.com/hubs/game. Ein Bot authentifiziert sich genauso wie überall sonst in dieser API: Sende Authorization: Bearer kirichess_pat_… bei der Verbindungsanfrage. Die eigene Website setzt ein kurzlebiges Sitzungs-JWT in den access_token-Query, weil ein Browser bei einem WebSocket-Handshake keinen Header setzen kann. Der Server akzeptiert ein kirichess_pat_…-Token in diesem Query weiterhin. Setze dort keines hin: Es wird im Proxy-Log von Fly, im Request-Log von Cloudflare und in der von Sentry erfassten Request-URL festgehalten.

Spielermethoden: JoinQueue, SubmitMove, Resign, OfferDraw, RespondDraw und LeaveQueue. Ereignisse: MatchFound, MovePlayed, GameEnded, DrawOffered, DrawDeclined, OpponentDisconnected und OpponentReconnected. WatchChallenge und UnwatchChallenge abonnieren diese Verbindung auf eine Herausforderung, die du erstellt hast; OfferRematch und AcceptRematch setzen eine beendete Partie fort. JoinAsSpectator bleibt anonym. Eine funktionierende Schleife ist: verbinden, JoinQueue, auf MatchFound warten, dann JoinGame(gameId), um die aktuelle Stellung zu bekommen und die Ereignisse dieser Partie zu abonnieren, bevor du SubmitMove aufrufst oder auf MovePlayed reagierst; ohne JoinGame trifft nie ein MovePlayed-Ereignis ein. Züge in einer über den Hub gepaarten Partie können auch über POST /api/v1/games/{id}/moves statt über den Hub gesendet werden, wenn das für deinen Client einfacher ist.