Le trading via l’API Kalshi exige de la précision tant sur le sens économique que sur la représentation des données. Un prix, une quantité de contrats, un accusé de réception d’ordre et un solde de compte sont des types d’informations différents. Les traiter comme des nombres interchangeables peut aboutir à une intégration qui envoie des requêtes valides tout en prenant la mauvaise décision.
Les schémas actuels méritent une attention particulière. Kalshi documente des prix en dollars à virgule fixe, des quantités fractionnaires de contrats et des grilles de prix propres à chaque marché. Les anciens exemples qui supposent des centimes entiers ou utilisent d’anciens champs indiquant le sens des ordres ne doivent pas servir de spécification universelle. L’intégration doit savoir quel point de terminaison et quelle version de réponse elle lit.
Cet article suit un ordre fictif tout au long du processus sans fournir de code de trading exécutable. Les prix, quantités et frais de l’exemple sont hypothétiques. L’objectif est d’expliquer comment une instruction autorisée devient un enregistrement de compte consultable, y compris lorsque le résultat reste incertain et que toute action supplémentaire doit attendre.
Commencer le trading via l’API Kalshi par une cartographie des schémas
Une cartographie des schémas consigne le sens, l’unité et les valeurs autorisées de chaque champ utilisé par le client. Elle doit distinguer les identifiants de marché, les prix, les quantités, les horodatages et les libellés d’état. C’est plus utile qu’un analyseur générique qui accepte tout champ portant un nom familier.
Pour chaque point de terminaison, déterminez si le champ décrit une instruction d’entrée, une réponse immédiate ou un enregistrement ultérieur du compte. Une quantité demandée n’est pas une quantité exécutée. Un prix moyen d’exécution n’est pas la limite soumise. Un horodatage peut décrire le traitement de la requête plutôt que l’événement sous-jacent.
Le guide antérieur sur l’API de trading Kalshi explique comment choisir l’interface de données appropriée. Construisez la cartographie des schémas autour de ces responsabilités. Lorsqu’une version change, cette cartographie doit révéler quels calculs et quelles décisions dépendent du champ modifié, au lieu de laisser son effet dissimulé dans le code de l’application.
Lire exactement les montants d’ordre Kalshi à virgule fixe
La documentation de Kalshi sur la virgule fixe décrit les chaînes de caractères représentant des montants en dollars et des quantités fractionnaires. Les montants d’ordre Kalshi à virgule fixe doivent être analysés au moyen d’une arithmétique décimale exacte ou d’une arithmétique entière avec une mise à l’échelle appropriée, en conservant leurs unités économiques tout au long du calcul.
Prenons un prix fictif de 0,4725 $ et une quantité de 12,50 contrats. Leur produit est de 5,90625 $ avant frais. Si un client tronque la quantité à douze, il modifie la position demandée. S’il arrondit le prix à 0,47 $ avant de vérifier la grille du marché, il modifie la limite de l’instruction.
La mise en forme à l’écran peut privilégier la lisibilité, mais l’enregistrement sous-jacent doit conserver la précision d’origine. Un libellé affichant environ 5,91 $ ne doit pas devenir la source utilisée pour reconstituer l’ordre. Conservez les montants exacts pour les calculs et distinguez explicitement toute présentation arrondie de l’enregistrement économique faisant autorité.
Valider la grille de prix actuelle
Le nombre de décimales affichées ne détermine pas si un prix est valide. Un marché peut définir une grille de prix autorisés, avec éventuellement des pas différents selon les plages. Le client doit utiliser les contraintes actuelles du marché plutôt que déduire un pas de cotation universel d’une convention de mise en forme.
Supposons qu’un marché hypothétique autorise des pas de 0,005 $ dans la plage concernée. Une limite calculée de 0,4725 $ ne correspondrait pas à cette grille fictive. Le client doit appliquer une règle explicite : rejeter la proposition pour examen ou choisir un prix autorisé qui respecte la limite économique approuvée.
Le sens de l’arrondi compte. Arrondir un prix d’achat maximal vers le haut peut dépasser le coût approuvé, tandis qu’arrondir un prix de vente minimal vers le bas peut conduire à accepter moins que ce qui a été approuvé. Toute transformation doit être visible avant l’autorisation et être vérifiée à nouveau si les contraintes du marché changent avant la soumission.
Préserver le sens des ordres d’une version de l’API à l’autre
Le côté correspondant à l’issue et le côté du carnet décrivent des aspects différents d’un ordre. Un utilisateur peut raisonner en termes d’achat de Yes ou d’achat de No, tandis qu’un point de terminaison peut exprimer les instructions par rapport à un carnet Yes unique. L’adaptateur doit établir délibérément la correspondance entre ces significations.
La documentation actuelle des ordres V2 de Kalshi décrit les sens bid et ask cotés du point de vue de Yes. Ne recopiez pas les anciens champs side et action dans une nouvelle requête sans examiner la sémantique actuelle. Un champ apparemment familier peut avoir un sens différent après une migration.
Utilisez des cas de validation compréhensibles par un humain. Pour chaque instruction prise en charge, décodez la requête proposée afin de retrouver l’exposition à l’issue et le prix voulus par l’utilisateur. Une personne chargée de la vérification doit pouvoir vérifier la correspondance sans interpréter mentalement les champs bruts. C’est particulièrement utile pour les décisions du côté No, où des prix complémentaires peuvent donner une apparence de plausibilité numérique à une correspondance erronée.
Relier le marché à l’intégralité de ses règles
L’identifiant de marché de l’API doit renvoyer à un enregistrement conservé des règles. Un programme qui sélectionne un symbole uniquement à partir d’une correspondance de mots-clés peut choisir la mauvaise date, le mauvais seuil ou la mauvaise source. Un ordre par ailleurs correct créerait alors une exposition au mauvais événement.
Pour l’ordre hypothétique, supposons que le contrat exige qu’une statistique mensuelle désignée soit supérieure à 75 lors de sa publication initiale. Consignez cette règle, la période d’observation et l’issue choisie avec l’intention d’ordre. Un contrat portant un nom similaire mais utilisant une publication révisée relève d’une autre décision de recherche.
Le guide sur l’automatisation Kalshi explique comment les contrôles de l’état des événements s’intègrent à un processus plus large. La vérification de la correspondance du contrat doit précéder l’autorisation de l’ordre, tandis que l’état actuel du marché est vérifié à nouveau peu avant la soumission. Une correspondance valide pour la recherche ne garantit pas que le marché accepte encore l’opération prévue.
Définir le périmètre des requêtes authentifiées
Le périmètre des requêtes authentifiées délimite l’endroit où l’application prouve son identité à la plateforme. Limitez le composant de signature aux requêtes qu’il est autorisé à prendre en charge. Les carnets de recherche, les tableaux de bord publics et les journaux de diagnostic ordinaires n’ont généralement pas besoin d’accéder aux éléments secrets de signature.
Le guide des clés API de Kalshi décrit des requêtes signées avec RSA utilisant un horodatage, une méthode et un chemin, les paramètres de requête étant exclus du chemin signé. Suivez précisément la spécification actuelle ; les octets exacts et les unités d’horodatage font partie du contrat d’authentification.
Une signature valide établit que la requête provient du détenteur des identifiants. Elle n’établit pas que l’opération demandée respecte la stratégie ou les limites de l’utilisateur. Ces vérifications applicatives doivent avoir lieu séparément. L’authentification doit être la dernière étape de communication contrôlée d’une instruction déjà validée, et non se substituer à l’autorisation économique.
Vérifier ensemble le compte et l’environnement
Les environnements de démonstration et de production doivent être clairement identifiés dans la configuration et dans l’état présenté à l’utilisateur. Une lecture authentifiée réussie n’est utile que si elle provient de l’environnement et du compte prévus. Un test qui pointe accidentellement vers un autre contexte peut donner une confiance trompeuse dans l’état de préparation.
Affichez l’environnement actif à côté de l’identité du compte, des autorisations prises en charge et de l’heure de la dernière lecture de données privées. Faites en sorte que les changements de configuration puissent être audités. Si un processus change d’identifiants ou d’environnement, exigez les vérifications de compte pertinentes avant de poursuivre tout processus de trading existant.
Les tests dans un environnement de démonstration peuvent vérifier le traitement des requêtes et le comportement de reprise, mais ils n’établissent ni la liquidité en production, ni les prix disponibles, ni les performances des prévisions. Distinguez ces affirmations. Le guide du bot API Kalshi développe des scénarios de validation qui évaluent le comportement opérationnel sans confondre une connexion de test réussie avec une stratégie économique validée.
Construire une intention d’ordre complète
Une intention d’ordre doit préciser le contrat, le sens économique, la quantité, le prix limite, la durée de validité et le contexte du compte. Elle doit aussi faire référence à la proposition de recherche et à l’autorisation qui l’ont produite. Enregistrez l’intention avant la transmission afin qu’une réponse perdue n’efface pas la raison d’un éventuel changement du compte.
Un identifiant local stable de l’intention est utile même lorsque la plateforme prend également en charge un identifiant d’ordre client. Consignez les deux selon leurs rôles respectifs. Ne supposez pas que le simple fait de nommer une requête offre automatiquement une protection illimitée contre les doublons ; vérifiez le comportement actuel de la plateforme et concevez la reprise autour des éléments du compte faisant autorité.
L’intention doit expirer lorsque son raisonnement ou son autorisation expire. Un processus retardé ne doit pas soumettre une ancienne proposition simplement parce qu’elle se trouve encore dans une file d’attente. Avant la transmission, vérifiez que le prix, la quantité, l’état du marché et la capacité du compte correspondent toujours à la décision approuvée.
Distinguer le coût observé du coût autorisé
Un carnet d’ordres montre un déroulement d’exécution possible à un instant donné. La limite de l’ordre définit le prix autorisé. Les deux peuvent produire des totaux différents, et le système de gestion du compte doit comprendre ces deux montants avant la soumission.
Imaginons un achat hypothétique de vingt contrats : huit sont proposés à 0,46 $ et douze à 0,48 $. Le coût d’achat observé est de 3,68 $ plus 5,76 $, soit 9,44 $ avant frais. Une limite de 0,48 $ pour les vingt contrats autorise un prix d’achat total pouvant atteindre 9,60 $. La différence est de 0,16 $.
Réservez la capacité selon les règles applicables au compte, en incluant les frais ou les autres montants requis. Le coût observé dans le carnet est utile pour évaluer l’occasion, mais il ne doit pas être confondu avec un résultat d’exécution garanti. Si les cotations changent, le type et la limite de l’ordre déterminent ce qui peut se produire ensuite.
Recommandez et gagnez des USDC
Recommandez et gagnez des USDCNotre programme d’affiliation paie en temps réel.
Conserver les frais dans des enregistrements distincts
Les frais peuvent dépendre des conditions du marché, des détails de l’exécution et des règles d’arrondi. Un client ne doit pas supposer qu’un taux unique codé en dur s’applique à tous les contrats ou qu’une estimation affichée constitue le montant finalement facturé. Conservez les enregistrements réels des frais associés aux exécutions et au rapprochement.
La documentation de Kalshi sur l’arrondi des frais explique pourquoi la précision peut compter dans les calculs du compte. En pratique, la conception doit conserver les valeurs décimales intermédiaires et appliquer les règles finales documentées à l’étape appropriée. Des arrondis prématurés répétés peuvent accumuler des écarts difficiles à diagnostiquer ensuite.
Pour l’exemple fictif de vingt contrats, supposons des frais totaux de 0,36 $ à des fins purement pédagogiques. Le coût total observé, frais compris, serait de 9,80 $. Ce chiffre doit être présenté comme une hypothèse tant que les enregistrements d’exécution réels n’ont pas établi le prix et les frais. Une estimation de recherche, une provision réservée et des frais effectivement réglés peuvent coexister sans être traités comme un seul et même nombre.
Limiter l’interprétation de la réponse de création
La réponse de création d’ordre peut fournir des identifiants et des informations immédiates sur les exécutions ou le reliquat. Interprétez ces champs selon la documentation actuelle du point de terminaison. Une réponse HTTP réussie ne signifie pas automatiquement que toute la quantité demandée a été exécutée, et ne règle pas non plus toutes les questions ultérieures concernant le compte.
Enregistrez la réponse avec son heure de traitement et l’intention d’origine. Si elle indique un reliquat non exécuté, déterminez si ce reliquat reste actif selon le mode de validité choisi pour l’ordre. Si elle indique des exécutions, reliez-les au registre du compte plutôt que de traiter la quantité demandée comme la quantité exécutée.
Une requête rejetée doit conserver le motif de son rejet. Une issue de transmission inconnue doit conserver son caractère incertain. Ces états appellent des actions de reprise différentes. Classer comme rejeté chaque appel local qui n’a pas abouti simplifie le programme, au prix de la perte de la distinction la plus susceptible de provoquer un doublement accidentel de l’exposition.
Rapprocher les quantités partiellement exécutées
Une exécution partielle modifie le compte à hauteur du montant exécuté, tandis que la partie non exécutée suit le comportement documenté de durée de validité de l’ordre. Une quantité restante peut demeurer active, expirer ou être annulée selon l’instruction et le résultat. Consignez ces deux dimensions.
Supposons que, sur l’ordre fictif de vingt contrats, huit soient exécutés à 0,46 $ et cinq autres à 0,48 $. Les treize contrats exécutés coûtent 3,68 $ plus 2,40 $, soit 6,08 $ avant frais. Sept contrats restent non exécutés. S’ils restent actifs à la limite de 0,48 $, leur engagement d’achat potentiel est de 3,36 $ avant les frais applicables.
Si les sept contrats restants sont annulés selon le comportement choisi pour l’ordre, cet engagement futur prend fin une fois cet état établi. Le compte détient toujours les treize contrats exécutés. Un enregistrement d’annulation ne doit pas effacer leur coût ni être interprété comme la preuve que l’ordre initial tout entier n’a eu aucun effet économique.
Examiner les réponses perdues avant toute nouvelle soumission
Une erreur réseau après transmission n’indique pas au client si la plateforme a accepté la requête. Conservez l’intention, les identifiants et la réservation pendant les recherches. Interrogez les enregistrements pertinents d’ordres et d’exécutions par les interfaces prises en charge, en conservant toute limite des éléments renvoyés.
Une liste vide d’ordres ouverts ne suffit pas à elle seule, car un ordre entièrement exécuté peut ne plus figurer dans le carnet. De même, une mise à jour privée retardée peut arriver après le résultat immédiat de la requête. Le rapprochement doit utiliser la combinaison appropriée de l’état actuel et de l’historique d’exécution plutôt que s’appuyer sur une seule vue commode.
Le guide antérieur du bot de trading via l’API Kalshi porte sur les requêtes dont les résultats peuvent être rapprochés. Sa distinction opérationnelle centrale s’applique ici : une nouvelle tentative de communication n’est pas une nouvelle autorisation d’acheter à nouveau. Les nouvelles instructions économiques doivent attendre que l’effet de l’action initiale soit compris ou explicitement traité selon des règles de reprise aux limites définies.
Rapprocher les flux privés et les lectures du compte
Les mises à jour en continu peuvent fournir rapidement des observations sur les ordres et les exécutions. Les lectures du compte peuvent fournir l’état actuel et les enregistrements historiques nécessaires après des interruptions. Une intégration robuste utilise chacun de ces moyens conformément à son rôle documenté et évite de supposer que l’un ou l’autre fournit à lui seul un registre parfait et ininterrompu.
Après la reconnexion, déterminez l’intervalle incertain, récupérez les enregistrements pertinents et dédupliquez les observations à l’aide d’identifiants stables. Une exécution observée à la fois dans un flux et lors d’une requête ultérieure ne doit contribuer qu’une fois à la quantité et au coût. Si un enregistrement change, conservez sa révision plutôt que de l’ajouter comme une exécution distincte sans lien avec la précédente.
Le registre de rapprochement du compte doit expliquer quels éléments étayent chaque position et chaque engagement ouvert. Si la couverture est incomplète, laissez l’état concerné non résolu. Afficher un total précis à partir de données incomplètes peut être plus trompeur que présenter un sous-total vérifié accompagné d’une anomalie de rapprochement clairement signalée.
Traiter séparément la fermeture du marché et le règlement du compte
L’état de négociation d’un marché détermine les opérations actuellement disponibles. La détermination de l’issue et le règlement final interviennent lors d’états ultérieurs du cycle de vie. Un marché fermé n’est pas simplement un marché actif dont la cotation est peu favorable, et un résultat d’événement connu n’équivaut pas à un versement achevé sur le compte.
Le client doit lire les informations actuelles du cycle de vie et appliquer les règles d’opération documentées. Ne réessayez pas à répétition une opération invalide pour l’état du marché. Conservez la raison pour laquelle elle a cessé d’être disponible et orientez tout travail restant sur le compte vers le rapprochement ou l’examen du règlement.
Le guide sur l’automatisation Polymarket fournit un autre contexte de compte pour réfléchir aux processus délégués. La séparation générale entre observation, pouvoir d’action et rapprochement reste utile, mais les mécanismes de garantie, de signature et de règlement doivent rester propres à chaque plateforme. Une interface commune ne doit pas masquer ces différences à l’opérateur.
Utiliser un registre de rapprochement du compte
Le registre doit relier l’état initial, les opérations exécutées, les frais, les transferts le cas échéant, les engagements ouverts et les positions finales. Chaque changement doit avoir une source identifiable. Un ajustement de solde sans explication peut faire correspondre un total tout en dissimulant l’erreur réelle d’intégration.
Pour l’exécution partielle de treize contrats, une personne chargée de la vérification doit voir le coût d’achat de 6,08 $, les frais réels associés et l’état final du reliquat de sept contrats. Les ventes ou le règlement ultérieurs doivent apparaître comme des changements distincts. Le registre ne doit pas remplacer l’historique par la seule quantité nette la plus récente.
Cet enregistrement sert à la fois à l’examen opérationnel et à l’analyse de recherche. La stratégie peut comparer l’exécution attendue à l’exécution réelle, tandis que le processus de gestion du compte vérifie les avoirs détenus et disponibles. Relier ces finalités au moyen d’identifiants communs évite des totaux incohérents entre un rapport de performance et l’écran utilisé pour autoriser une nouvelle exposition.
Examiner les changements de schéma comme des changements de comportement
Une migration de schéma peut modifier davantage que l’analyse des données. Une nouvelle précision, une nouvelle sémantique du sens des ordres ou de nouveaux champs d’état peuvent modifier la construction des ordres, les contrôles des limites et le rapprochement. Traitez une migration comme un examen du comportement économique plutôt que comme un exercice mécanique de renommage.
Utilisez des exemples conservés pour vérifier que le nouveau client décode la même exposition et le même montant prévus. Incluez des quantités fractionnaires, des prix inférieurs au centime, des exécutions partielles et des décisions du côté No lorsque ces possibilités sont prises en charge. Confirmez que les valeurs inconnues produisent une exception contrôlée au lieu de revenir silencieusement à une ancienne hypothèse par défaut.
Le guide antérieur de l’API pour bot Kalshi développe l’idée d’un adaptateur testable. Cette délimitation est utile ici : le reste de l’application doit recevoir des enregistrements normalisés et bien définis, tandis que l’adaptateur reste chargé de traduire les champs actuels de la plateforme sans perdre leur provenance ni leur précision.
Vérifier le trading via l’API Kalshi comme un processus de gestion du compte
Un examen complet suit une instruction depuis la sélection du contrat jusqu’à l’enregistrement final du compte. Il vérifie les unités, le sens, l’authentification, les contraintes, l’autorisation, les preuves d’exécution et le traitement de l’incertitude. Réussir uniquement l’étape de construction de la requête laisse sans examen la majeure partie du processus économique.
Commencez par des vérifications du compte en lecture seule et des cas de test contrôlés adaptés à l’environnement autorisé. Testez les exécutions partielles, les prix rejetés, les réponses perdues, les reconnexions et les changements de schéma. Chaque cas doit aboutir à un registre reproductible ou à une exception explicite qui empêche toute poursuite sans éléments suffisants.
Le résultat est une intégration dont les nombres conservent leur sens à chaque passage d’un composant à l’autre. Le traitement décimal exact évite les erreurs d’unité, la documentation actuelle évite les hypothèses héritées des anciennes versions et le rapprochement établit ce qui s’est réellement passé. Ensemble, ces éléments font de l’API une partie utilisable d’un processus de gestion du compte contrôlé, plutôt qu’un simple moyen d’envoyer des requêtes authentifiées.