Handelsbot för Kalshi-API: begäranden som går att stämma av

Definiera den ekonomiska avsikten före begäran

Strategin ska uttrycka önskemål i termer som är meningsfulla utanför en HTTP-nyttolast. En avsikt identifierar kontraktet, önskad riktningsförändring, högsta kvantitet, godtagbart pris och tidsfrist. Den dokumenterar också godkännandet bakom åtgärden och kontotilldelningen den får förbruka.

Posten skiljer sig från ett begärandeförsök. Ett försök har tidsstämpel, destination, signatur och svar eller fel. Flera försök kan höra till en avsikt men klienten ska inte förväxla försöksantal med antal godkända positioner.

Spara avsikten beständigt före åtgärden. Om klienten skickar först och sparar senare lämnar en krasch däremellan en kontoeffekt utan lokal förklaring. Att skriva först låter en omstartad process upptäcka en olöst avsikt och undersöka i stället för att anta att ingen affär skett.

Posten behöver inte vara stor. Den ska innehålla tillräckligt för att återskapa föreslagen ekonomisk åtgärd och skilja den från andra förslag. En orsakskod som prognosingång är bara användbar om den pekar på den specifika prognos och policyversion som godkände ordern.

Designguiden för bot-API:er på prognosmarknader diskuterar uppdelningen mellan policy och kontoåtkomst. Vid gränsen är huvudprincipen att transportdetaljer ska verkställa en godkänd avsikt, inte skapa ny handelspolicy genom oavsiktliga standardvärden.

Autentisering för en handelsbot för Kalshi-API

Autentisering för en handelsbot för Kalshi-API ska följa aktuellt officiellt schema exakt. Guiden till autentiserade begäranden anger en API-nyckelidentifierare, en millisekundtidsstämpel och en base64-kodad RSA-PSS-signatur med SHA256. Det signerade meddelandet sammanfogar tidsstämpel, HTTP-metod och fullständig begärandesökväg utan frågeparametrar.

De flesta implementationsfel här är representationsfel. En tidsstämpel i sekunder är inte en i millisekunder. En sökväg upprepad för att två hjälpfunktioner båda lägger till prefix är inte avsedd sökväg. Signering av annan metod än den skickade ger en begäran vars auktoriseringsbelägg inte beskriver åtgärden på nätverket.

Bygg destination och signeringssökväg från samma validerade begärandedefinition. Det minskar risken att en hjälpfunktion signerar en sökväg medan en annan skickar till annan plats. Tester ska täcka sökväg med frågeparametrar och utan dem.

Håll signering skild från vanlig diagnostikutmatning. Loggar kan behålla metod, säker sökvägsbeskrivning, avsiktsidentifierare och svarsklassificering utan privat nyckel. En supportexport ska inte exponera materialet som godkänner framtida kontoåtgärder.

Behandla autentiseringsfel som skäl att granska autentiseringsuppgifter, klockhantering och begärandekonstruktion. Högfrekvent upprepning av samma ogiltiga begäran reparerar den inte. Strategin ska sakna förmåga att skapa ny exponering tills klienten fastställt giltig autentiserad kontovy.

Använd aktuell terminologi för händelseorder

Aktuell V2-referens för orderskapande använder händelseordersökvägen, köp- eller säljsida i boken, kontraktsantal som sträng och dollarpris med fast precision. Priset uttrycks på Ja-skalan: bid köper Ja, medan ask säljer Ja. En äldre nyttolast ska inte kopieras till en ny klient utan granskning av aktuellt kontrakt.

Översätt strategispråk till representationen på ett ställe. En strategi kan tala om att skaffa Nej-exponering medan begäran använder ett pris på Ja-skalan. Översättningen ska vara uttrycklig och testad så att en senare visningsändring inte tyst vänder en order.

Använd ett hypotetiskt exempel för omvandlingen. Om avsedd ekonomisk limit är att betala högst 32 cent för Nej i ett enkelt binärt kontrakt är kompletterande pris på Ja-skalan 68 cent. Adaptern måste bevara avsedd riktning och limit tillsammans. Att bara ändra sida med en orelaterad priskonvention kvar kan ge en annan affär.

Håll begärande- och svarsmodeller separata. Ett kompakt skapandesvar kan bekräfta en order utan alla fält från en full kontoordervy. Klienten ska inte fylla saknade fält med optimistiska antaganden som helt avslutad eller ingen återstående exponering.

En schemaavvikelse ska stoppa den åtgärdsvägen synligt. Om ett nödvändigt fält saknas eller har obekant innebörd kan tyst accepterande förstöra senare redovisning. Ett snävt fel är att föredra framför en brett lyckad begäran med okänd ekonomisk tolkning.

Hantera priser med fast precision i en handelsbot för Kalshi-API

Priser med fast precision i en handelsbot för Kalshi-API ska förbli exakta genom validering, aritmetik och serialisering. Officiell guide till representation med fast precision beskriver dollarsträngar, bråkdelar av kontrakt och marknadsspecifika prisintervall. Antagandet att varje giltigt pris är en hel cent räcker inte längre.

Använd decimalaritmetik eller noggrant definierad skalad heltalsrepresentation. Den viktiga egenskapen är att giltig indata som 0,1250 behåller avsett värde. Binär flyttalsavrundning ska inte avgöra om ett föreslaget pris ligger på marknadens godkända rutnät.

I en illustrativ beräkning har 12,50 kontrakt till 0,2400 dollar köpesumman exakt 3 dollar före avgifter. En tolk som tappar det halva kontraktet registrerar 2,88 dollar i stället och lämnar skillnaden 12 cent. En tolk som förväxlar dollar och cent skapar ett mycket större fel.

Validera priser mot aktuellt marknadsrutnät före inlämning. Om en teoretisk modell föreslår 0,237 dollar men relevant band tillåter ett annat steg behöver klienten angiven avrundningspolicy. Avrundning mot aggressivare pris kan bryta strategins högsta kostnad, så policyn måste respektera ekonomisk limit.

Behåll ursprunglig indata och normaliserat värde i diagnostikbelägg. Då kan en granskare skilja källfel från omvandlingsfel. Det gör också senare representationsändringar lättare att testa eftersom samma dokumenterade fall kan köras genom gamla och nya adaptrar.

Skilj kontraktsantal, pris och kassa

Tre kvantiteter visas ofta nära varandra på en orderskärm: kontrakt, dollar per kontrakt och total kassa. De är inte utbytbara. Ett fält som heter belopp är för vagt för intern modell om inte enheten är fast och tydligt dokumenterad.

Använd namn och typer med innebörd. Kontraktskvantitet kan ha bråkdelar. Limitpris beskriver belopp per kontrakt. Uppskattad debitering inkluderar kvantitet gånger pris och utrymme för tillämpliga kostnader. Faktisk kassarörelse kommer från dokumenterat kontoresultat och kan skilja sig från uppskattningen.

En hypotetisk avsikt att köpa 25 kontrakt till 44 cent har köpesumman 11 dollar. Den instruerar inte att spendera 25 dollar och är ingen order på 44 dollar. Skillnaderna verkar uppenbara men tappas lätt när flera ändpunkter använder olika fältnamn eller enheter.

Bygg enhetskontroller vid begärandegränsen. Ett pris utanför tillåtet kontraktsintervall, negativ köpkvantitet eller kassauppskattning som inte kan stämmas av med storlek och pris ska avvisas före signering. Sådana kontroller är mer användbara än att upptäcka misstaget efter handelsplatsens avslag.

Översikten över handels-API:er för prognosmarknader placerar representationerna i ett bredare integrationssammanhang. En stark klient håller enheter uttryckliga hela vägen från källobservation till kontorapport i stället för att förlita sig på ett gränssnitt som härleder dem vid slutet.

Bevara en identifierare genom osäkra försök

Skapa en lokal avsiktsidentifierare och lämplig klientorderidentifierare före inlämning. Lagra förhållandet till serverns orderidentifierare när den blir känd. Identiteterna gör det möjligt att koppla senare kontopost till åtgärden som skapade den.

Officiell snabbstart beskriver dubblettupptäckt genom klientorderidentifieraren. Funktionen är användbar men klienten ska ändå ha egen avsiktsjournal och granska aktuella kontobelägg. Gör inte en dokumenterad dubblettkontroll till ett ostyrkt påstående att varje begäran kan spelas upp för evigt under alla förhållanden.

Om en order får timeout efter överföring är utfallet okänt. Klienten ska behålla ursprunglig ekonomisk avsikt och reserverad kapacitet. Den kan sedan granska order och avslut eller göra ett dokumenterat nytt försök med lämplig identitet bevarad. Att skapa ny identifierare som standardsvar på osäkerhet riskerar ett andra oberoende åtagande.

Ett dubblettsvar kan själv vara användbart belägg. Det kan ange att ursprunglig åtgärd nådde handelsplatsen men bevisar inte i sig hur mycket som avslutats. Följ identiteten till kontoposten och lös återstående exponering.

Behåll journalen genom omstarter. En identifierare bara i processminnet försvinner just när återhämtning kan behöva den mest. Beständighet är ingen abstrakt databaspreferens här; den bevarar kopplingen mellan godkänt beslut och kontoeffekter som redan kan finnas.

Klassificera policyn för nya försök i en handelsbot för Kalshi-API

En policy för nya försök i en handelsbot för Kalshi-API ska skilja ogiltiga indata, nekad behörighet, frekvenstryck, transportfel och osäkert ekonomiskt resultat. Kategorierna löses inte med samma svar. En allmän försöksslinga kan göra ett litet anslutningsproblem till ett större kontoproblem.

Ogiltigt prisrutnät eller felaktig kvantitet kräver rättning. Nekad åtkomst kräver förståelse av kontobehörighet eller status. Frekvenstryck kräver avvägd takt och prioritering. Förlorat svar efter skrivning kräver avstämning. Tillfälligt läsfel kan tillåta nytt observationsförsök utan att godkänna ny position.

Varje nytt försök ska fortfarande respektera avsiktens frist. En prisbaserad ingång rimlig före publicering kanske inte gäller efter flera sekunders fördröjning. Lyckad leverans av en förfallen affär är inte lyckat utförande av ursprunglig policy.

Använd avgränsad backoff för upprepbart kommunikationsarbete med gräns för både försök och förfluten tid. Gränserna ska väljas efter uppgiftens värde och brådska. Uttömd försökspolicy ska ge ett tydligt olöst tillstånd, inte en osynlig slinga som fortsätter för evigt.

Dokumentera skälet för varje försök. En senare granskare ska se om klienten hämtade färska belägg, provade en dokumenterat dubblettsäker åtgärd igen eller undersökte osäkerhet. Skillnaden hjälper till att identifiera om problemet faktiskt ligger i handelsplatsens svar, lokal konstruktion av begäranden eller strategins tidsantaganden.

Håll läskapacitet tillgänglig för återhämtning

En klient kan förlora användbar kontroll om rutinmässig avfrågning förbrukar kapaciteten för att granska en osäker order. Frekvensbudgetering ska därför reservera utrymme för kontoåterhämtning och riskminskning i stället för att värdera varje begäran lika.

Aktuella Kalshi-gränser använder tokenkostnader och kontospecifika budgetar. Dokumentationen om frekvensgränser skiljer läs- och skrivresurser och beskriver aktuella routningsdetaljer. Klienten ska hämta tillämplig konfiguration i stället för att anta ett fast antal begäranden per sekund för varje konto och ändpunkt.

Tänk på en hypotetisk schemaläggare med begränsat läsutrymme. Full skanning av hundratals orelaterade marknader kan vara lägre prioriterad än kontroll om en färsk order avslutats. Om skanningen blockerar kontrollen kan strategin förbli osäker längre och missa legitima åtgärder eller göra osäkra.

Batchning och strömning kan minska arbete men tar inte bort behovet att förstå ändpunkters innebörd. En batch kan ha blandade utfall. En ström kan kopplas bort. Schemaläggaren ska prioritera informationen som fastställer kontots aktuella förpliktelser.

Mät begärandekostnad efter syfte. Skilj upptäckt, normal observation, orderuppföljning och återhämtning. Då kan bakgrundsarbete minskas vid ökat tryck utan att oavsiktligt inaktivera kontrollerna som skyddar kontot.

Rekonstruera delavslut utan dubbelräkning

Ett delavslut ändrar både innehav och återstående orderexponering. Klienten behöver bevara båda. Begärd kvantitet 30 med 12 avslutade och 18 fortfarande aktiva skiljer sig från en stängd order med bara 12 avslutade.

Vet om varje fält är kumulativt eller inkrementellt. Om ett svar visar total avslutad kvantitet 12 och ett senare 20 är extra avslutet åtta. Summering av båda totalerna skapar en falsk position på 32. Inkrementella avslutshändelser kräver annan behandling inklusive dubblettupptäckt.

En annullering kan konkurrera med ett avslut. Slutposten måste tillåta att viss kvantitet utförts innan återstående order togs bort. Lyckad annullering ångrar inte tidigare avslut eller bevisar att ursprunglig begäran saknade effekt.

Använd kontopositioner som dubbelkontroll men inse att ögonblicksbilder kan representera olika observationstider. Målet är förklarad avstämning, inte att tvinga varje ändpunktssvar att vara identiskt varje ögonblick. Bevara tidsstämplar och beläggsekvensen som användes för att lösa skillnaden.

Guiden till kontosynkronisering på prognosmarknader utvecklar resonemanget på systemnivå. Vid API-gränsen är kärnuppgiften att bevara tillräcklig identitets- och kvantitetsdetalj för korrekt senare avstämning.

Testa gränsen med avsiktliga fel

Användbara klienttester fokuserar på fel som kan ändra ekonomisk innebörd. Testa bråkdelskvantitet, pris vid bandgräns, förfallen avsikt och okänt svarsfält. Varje fall ska ha ett förväntat beslut som kan granskas utan verklig affär.

Testa sedan kommunikationsosäkerhet. Simulera att svar försvinner efter accepterad begäran. Starta om klienten medan avsikten är olöst. Förväntat beteende är återställning av befintlig avsikt och granskning av kontoutfallet, inte nytt strategibeslut från tomt tillstånd.

Testa även felaktiga källdata. Saknat pris ska inte bli noll. En sträng som inte kan tolkas ska inte bli standardkvantitet. Förklarat avslag på oanvändbara data är ett lyckat testresultat.

Håll autentiseringsuppgifter och verkliga kontoåtgärder utanför vanliga automatiska testkörningar. Kontrollerat testunderlag kan fastställa omvandlings- och klassificeringsbeteende. En separat auktoriserad demoövning kan sedan testa anslutning utan att behandla låtsaslikviditet som belägg för verklig utförandekvalitet.

Behåll slutligen felfallen medan API:et utvecklas. Värdet hos en regressionsuppsättning är bevarade ekonomiska förväntningar när begärandeformen ändras. En uppdatering är godtagbar när den fortfarande ger avsett avgränsat beteende, inte bara när den kompilerar eller ger lyckad HTTP-status.

Gör API-ändringar till en granskad översättningsuppgift

En API-ändring ska utlösa granskning av adapterns antaganden. Nya fältnamn kan vara enkla men ändrad priskonvention, kvantitetsinnebörd eller fullständighet i svar kan ändra kontobeteende även om koden fortfarande kör.

Håll en liten kompatibilitetspost med granskad dokumentation, begärandeformer som stöds och testfall som fastställer innebörden. Beskriv inte en klient som permanent kompatibel. Kompatibilitet är belägg knutna till version och testad operationsuppsättning.

Jämför normaliserade resultat från lagrade exempel vid migrering. Samma ekonomiska avsikt ska ge likvärdiga limiter och riktning i ny representation. Samma avslutshistorik ska ge samma förklaring av position och kassa. Skillnader ska förstås före nya åtgärder aktiveras.

En snäv adapter gör arbetet hanterbart. Strategiforskning kan fortsätta tala om uttryckliga kontrakt, sannolikheter och ekonomiska gränser medan en granskad gräns hanterar aktuella handelsplatskonventioner. Uppdelningen gör API-underhåll till ett konkret översättningsproblem och ger ägaren tydligare grund för när klienten kan agera igen.

Relaterade guider och genomarbetade exempel

• Automatiserad handel med Kalshi-API: spåra varje beslut — Bygg en granskningsbar klient från marknadsupptäckt till kontoavstämning.
• Kalshis handels-API: välj rätt datayta — Välj marknads- och kontogränssnitt med hänsyn till frekvensbudgetar och datakonventioner.