En API-bot för Kalshi bör förtjäna sin driftomfattning genom visat beteende. En lyckad anslutning eller en accepterad order visar inte hur programmet hanterar delavslut, dubbla meddelanden, ändrade marknadsbegränsningar eller en krasch efter inskickning. Dessa fall avgör om kontoposten förblir tillförlitlig när vanliga antaganden inte håller.
Acceptanskriterier översätter breda påståenden som ”tillförlitlig” eller ”säker” till observerbara resultat. De anger kontots starttillstånd, den införda händelsen, åtgärden boten får vidta och de poster som väntas efteråt. Ett test som inte kan ange sitt förväntade ekonomiska resultat fastställer sannolikt inte mycket om botens beteende.
Den här guiden presenterar hypotetiska acceptansövningar för en behörig utvecklingsprocess. Siffergränser och priser är påhittade. Demotester, simulerade svar och återuppspelade poster kan utvärdera programvarubeteende utan att bevisa likviditet i produktion eller strategilönsamhet. Verklig handelsbefogenhet förblir ett separat beslut avgränsat av kontoägarens instruktioner.
Skriv acceptanskriterierna för Kalshi-boten först
Acceptanskriterier för en Kalshi-bot bör beskriva utfall före implementationsdetaljer. Att spela upp samma avslut två gånger måste exempelvis ändra positionen en gång. Ett utgånget förslag får inte bli en ny order. Ett förlorat svar måste skapa ett olöst tillstånd i stället för att automatiskt frigöra reservationen.
Ange beläggen som krävs för godkänt resultat. Ett konsolmeddelande som säger ”dubblett ignorerad” räcker inte om huvudboken ändå dubbelräknade antalet. Granska den resulterande positionen, avgifterna, ordertillståndet och journalen. Acceptansresultatet bör vara begripligt för någon som inte skrev den berörda koden.
Den äldre guiden till en Kalshi-handelsbot med API och Python beskriver tillförlitlig utformning bortom en språkspecifik klient. Använd perspektivet här: den viktiga egenskapen är beteendet vid kontogränsen. Valet av programmeringsspråk tar inte bort behovet att verifiera ekonomisk betydelse.
Fastställ ett känt kontostarttillstånd
Varje övning behöver ett starttillstånd som kan kontrolleras oberoende. Ange positioner, aktiva order, tillgänglig kapacitet och olösta avsikter. Utan en känd baslinje kan en senare avvikelse skyllas på ett oförklarat tidigare förhållande i stället för beteendet som prövas.
Börja en hypotetisk testsvit med tio ja-kontrakt, en aktiv order på fem kontrakt och en händelsegräns på trettio kontrakt. Boten bör beräkna femton kontrakt i befintlig eller möjlig exponering enligt den enkla policyn. En ny begäran om tjugo skulle överskrida gränsen om alla antal blev positioner.
Håll testfallen åtskilda från verklig kontoinformation. Ett test bör aldrig tyst låna produktionsuppgifter för autentisering eller anta att en välbekant marknadsidentifierare är harmlös. Identifiera miljön tydligt och använd passande kontroller. Syftet är att pröva ett avgränsat beteende, inte att upptäcka kontotillståndet genom oavsiktligt genomförande.
Pröva exakta decimalbelopp
Aktuell Kalshi-dokumentation använder fastpunktspriser och antal. Acceptans bör omfatta värden som en parser för heltalscent eller hela kontrakt skulle hantera fel, samtidigt som övningens hypotetiska marknadsbegränsningar respekteras.
Använd ett påhittat giltigt pris på 0,3375 dollar och ett antal på 8,40 kontrakt. Köpvärdet är 2,835 dollar före avgifter. Den förväntade huvudboken bör bevara den exakta produkten i steget där den är meningsfull och sedan tillämpa dokumenterade slutliga avrundningsregler separat. Att kapa antalet till åtta är ett fel.
Pröva också ogiltiga format, saknade enheter och värden utanför tillåtna intervall. Boten bör avvisa eller isolera ett tvetydigt belopp i stället för att gissa. En parser som accepterar felaktiga värden för att den kan hitta några siffror skapar en farlig skillnad mellan vad indata säger och vad kontot får göra.
Pröva prisstegen oberoende av precisionen
Ett decimalvärde kan vara syntaktiskt giltigt men ligga utanför marknadens tillåtna prissteg. Boten bör läsa aktuella prisbegränsningar och verifiera den föreslagna gränsen mot dem. En sträng med fyra decimaler är inte automatiskt ett giltigt fyrdecimaligt pris på varje marknad.
I ett hypotetiskt band med steg om 0,005 dollar ligger ett avsett högsta köppris på 0,3375 dollar mellan 0,335 och 0,340 dollar. Om policyn avrundar till ett tillåtet köppris får det inte överstiga det godkända högsta priset. Avrundning uppåt till 0,340 dollar skulle bryta mot just den instruktionen.
Pröva en ändring av prisstegen mellan förslagets skapande och inskickning. Det förväntade beteendet bör vara ny validering, en godkänd justering eller avvisning för granskning. Boten bör inte upprepade gånger skicka ett ogiltigt pris och anta att varje avslag är ett tillfälligt nätverksproblem.
Pröva ekonomisk riktning med fall på vanligt språk
En orderadapter bör korrekt översätta användarens avsedda utfallsexponering till den aktuella ändpunktens riktningsfält. Kalshis dokumentation om orderriktning är referensen för att tolka aktuella svarsfält. Förfrågningars betydelse bör också kontrolleras mot den exakta ändpunkten som används.
Skriv fall på människors språk innan serialiserade data granskas: öka ja-exponeringen till ett högsta pris, minska en befintlig position till ett lägsta pris eller uttryck ett beslut på nej-sidan som stöds genom det aktuella gränssnittet. Avkoda varje begäran tillbaka till vanligt språk och jämför med den ursprungliga avsikten.
Ta med fall med komplementpriser eftersom de kan dölja fel. Ett numeriskt rimligt värde på fel sida kan skapa giltig men oavsedd exponering. Att klara en schemavaliderare bevisar bara att begäran har en godtagbar form; acceptans måste också bevisa att formen bär den avsedda ekonomiska instruktionen.
Pröva behörighetsgränsen
Ge boten tillstånd att observera en bred marknadslista men bara handla en liten godkänd delmängd. Presentera sedan ett attraktivt förslag utanför delmängden. Det förväntade resultatet är ett dokumenterat avslag utan signerad eller skickad order.
Upprepa övningen med en ordertyp som inte stöds, ett för stort antal och ett utgånget godkännande. Varje fall bör stoppas vid rätt kontroll. En modellgenererad förklaring bör inte kunna åsidosätta policyn genom brådskande språk eller påståenden om ovanligt hög tilltro.
Guiden om Polymarket-automation jämför manuella, övervakade och delegerade flöden. Den användbara allmänna lärdomen är att befogenhet måste vara uttrycklig i varje steg. För Kalshi-boten bör acceptansposten visa exakt vilken åtgärd som nekades och vilket observations- eller avstämningsarbete som fortfarande var tillåtet.
Pröva samtidiga förslag mot en gräns
Två förslag kan klara kontrollen var för sig men tillsammans överskrida en gemensam gräns. Acceptans bör införa dem tillräckligt nära i tid för att visa en kapplöpning mellan kapacitetskontroll och registrering av reservationer. Det förväntade beteendet är samordnat godkännande, inte två oberoende godkännanden från samma inaktuella ögonblicksbild.
Återgå till den hypotetiska trettiokontraktsgränsen där femton redan innehas eller är bundna. Två förslag begär tio vardera. Bara ett tillägg på tio kontrakt ryms om policyn räknar det största möjliga genomförda antalet; det andra skulle höja möjlig exponering till trettiofem. Boten måste avvisa, storleksändra enligt godkänd policy eller skjuta upp det andra förslaget.
Granska den gemensamma huvudboken efter båda besluten. Den bör innehålla en konsekvent reservationstotal och ett skäl för det uppskjutna eller avvisade förslaget. Testet bör inte godkännas bara för att ett senare avslag från handelsplatsen råkade hindra överskridandet. Programmets egen godkännandegräns behöver fungera.
Pröva idempotent avslutshantering
Idempotent avslutshantering betyder att mottagning av samma ekonomiska avslut mer än en gång ger samma kontoeffekt som mottagning en gång. Strömmar, återanslutningar och senare kontoförfrågningar kan alla ge överlappande belägg. Boten måste känna igen samma avslut genom dess stabila identitet och dokumenterade revisionsbetydelse.
Börja med tio kontrakt och inför ett avslut på fyra. Den resulterande positionen är fjorton. Spela upp samma avslut genom en andra väg; resultatet bör förbli fjorton och tillhörande avgift registreras en gång. Ett andra separat avslut på fyra kontrakt bör sedan ge arton.
Testet skiljer dubbel transport från upprepad legitim handel. Dubblettrensning enbart efter antal och pris skulle felaktigt kasta bort separata avslut som råkar ha samma villkor. Posten behöver identifierare och ursprungsinformation som är tillräckligt starka för att bevara verkliga genomföranden men ta bort upprepade observationer av samma avslut.
Pröva delavslut och återstodens tillstånd
Ett delavslut bör uppdatera innehavet med det genomförda antalet och bevara korrekt tillstånd för den ogenomförda delen. Det valda giltighetsbeteendet spelar roll. En kvarliggande återstod och en annullerad omedelbar återstod är olika kontoåtaganden även när det genomförda antalet är identiskt.
I en hypotetisk order på tolv kontrakt genomförs fem till 0,40 dollar, till en kostnad på 2 dollar före avgifter. Sju förblir ogenomförda. En övning lämnar de sju aktiva; en annan avslutar dem enligt det valda dokumenterade beteendet för omedelbara order. Förväntad reservation och orderpanel bör skilja sig därefter.
Boten bör aldrig härleda att varje delavslut ger en aktiv återstod. Den bör också undvika att behandla annullerad återstod som annullering av de genomförda fem. Kontrollera position, köpkostnad, avgifter och slutligt ordertillstånd tillsammans så att testet verifierar hela det ekonomiska resultatet.
Hänvisa och tjäna USDC
Hänvisa och tjäna USDCVårt affiliateprogram betalar i realtid.
Pröva ett förlorat inskickningssvar
Simulera att en order skickas och att svaret sedan går förlorat. I ett fall accepterade handelsplatsen ordern, i ett annat avvisade den ordern. Boten har till en början samma lokala symtom, så dess första svar bör bevara osäkerheten och undersöka ursprungsavsikten.
Det förväntade beteendet omfattar att behålla relevant reservation, undvika en ny orelaterad order och granska de order- och avslutsposter som stöds. Testet bör verifiera att en tom lista över öppna order inte ensam avslutar ärendet om ordern kan ha genomförts helt.
En klientorderidentifierare kan hjälpa till att koppla samman poster, men boten måste verifiera handelsplatsens aktuella dubbletthantering i stället för att anta obegränsat genomförande exakt en gång. Lokal idempotent hantering, förfrågningsidentitet och garantier för extern acceptans är besläktade verktyg med olika omfattning. Acceptanskriterierna bör ange vilken garanti som faktiskt prövas.
Pröva en krasch efter acceptans
En särskilt användbar övning i återhämtning vid omstart stoppar processen efter att handelsplatsen accepterat en order men innan den lokala framgångsposten sparats. Vid omstart bör boten läsa sin beständiga avsikt och stämma av det externa tillståndet innan den avgör om något behöver skickas.
Om den bara spelar upp varje avsikt som saknar en lokal slutförandemarkering kan den skapa dubbel exponering. Det förväntade återhämtningsresultatet är en ekonomisk order kopplad till ursprungsavsikten, med eventuellt aktivt antal eller genomförande återgivet i kontohuvudboken. Om tillgängliga belägg inte kan fastställa sambandet bör resultatet förbli uttryckligen olöst.
Den äldre guiden till en automatisk handelsbot för Kalshi förklarar driftstillstånd. Omstart bör vara en övergång genom observation och avstämning, inte ett automatiskt hopp till obegränsad handel. Acceptans bör granska övergången i stället för att bara bekräfta att processen startar korrekt.
Pröva annullering under ett avslut
Inför ett avslut medan en annullering pågår. Boten bör stämma av det genomförda antalet och den del som faktiskt togs bort. En annulleringsbegäran uttrycker en avsikt; den hindrar inte retroaktivt ett avslut som redan skett.
Anta för en påhittad aktiv återstod på nio kontrakt att tre genomförs innan annulleringen tar bort de andra sex. Kontopositionen ökar med tre och åtagandet för sex upphör. Ett ersättningsförslag bör använda det resulterande tillståndet i stället för att anta att alla nio annullerades.
Kontrollera förklaringen till operatören liksom siffrorna. Gränssnittet bör visa varför slutpositionen skiljer sig från antalet som syntes när annulleringen började. En allmän märkning som ”annullerad” kan dölja det ytterligare avslutet och uppmuntra en för stor ersättning även om den underliggande huvudboken råkar innehålla rätt antal.
Pröva ändrat marknadstillstånd
Ett förslag kan vara giltigt när det skapas och ogiltigt när det når inskickning. Inför en paus, stängning eller ändrad marknadsbegränsning mellan stegen. Det förväntade beteendet bör följa aktuella handelsplatsregler och programmets policy utan försök att kringgå tillståndet genom upprepade förfrågningar.
Kalshis dokumentation om marknadslivscykeln beskriver aktuella handels- och avräkningssteg. Acceptanssviten bör använda deras betydelser i stället för att anta att en allmän flagga för öppet eller stängt täcker varje ansvar.
Analys kan fortsätta medan orderskapande är avstängt, och avstämning kan fortfarande behövas efter handelsslut. Pröva förmågorna separat. En bot som stoppar all kontoobservation när marknaden stänger kan missa just de poster som behövs för att fastställa slutliga positioner, avgifter och avräkning. Driftbegränsningar bör begränsa åtgärder utan att radera skyldigheten att redovisa tidigare åtgärder.
Pröva strömluckor och överlappande återhämtningsläsningar
Koppla från den privata strömmen medan avslut sker och återanslut sedan och hämta kontohistorik. Återhämtningen kan möta både avslut som redan sågs före luckan och nya avslut. Den förväntade huvudboken bör omfatta varje ekonomisk händelse en gång och identifiera det återhämtade intervallet.
En användbar övning returnerar poster i en besvärlig ordning. En sen uppdatering bör inte skriva över ett nyare tillstånd bara för att den kom senare lokalt. Bevara händelseidentifierare, relevanta tidsstämplar och dokumenterad versionsinformation när sambanden mellan poster fastställs.
Om fullständig täckning inte kan fastställas bör boten behålla ett undantag och begränsa ny exponering enligt sin policy. En till synes exakt position härledd ur en ofullständig ström är ingen lyckad återhämtning. Testet godkänns när resultatet antingen är verifierat eller ärligt olöst, med ett tydligt nästa steg.
Pröva anropsbegränsningar utan att ändra avsikten
En läsning eller skrivning som begränsas i anropsfrekvens bör inte få boten att ändra förfrågningens ekonomiska betydelse. Väntan mellan återförsök kan ändra tidpunkten men får inte tyst öka antalet, vidga en gräns eller skapa en ny oberoende avsikt. Försenade förslag kan löpa ut under väntan.
Pröva både vanlig begränsning av marknadsdataanrop och en privat avstämningsförfrågan som behövs för att lösa osäkerhet. Boten bör prioritera efter driftspolicyn och bevara tillräcklig kapacitet för väsentlig kontoobservation där gränssnittet tillåter det. Den bör inte förbruka varje tillgänglig förfrågan på noteringsuppdateringar av lågt värde.
Dokumentera den faktiska fördröjningen i analys- och genomförandehistoriken. En strategi kan inte tillskriva sig ursprungsnoteringen om anropsbegränsning sköt upp beslutet. Acceptansresultatet bör visa att inaktuella förslag validerades på nytt eller avvisades och att olösta inskickningar förblev kopplade till sina ursprungliga reservationer.
Pröva autentiseringsfel som ett kontrollerat tillstånd
Utgångna, återkallade eller felkonfigurerade autentiseringsuppgifter bör ge ett tydligt tillstånd där förmågor har gått förlorade. Boten bör undvika att exponera hemligheter i felmeddelanden och bör inte falla tillbaka till ett oavsiktligt valt konto eller en oavsedd miljö bara för att få förfrågan att lyckas.
Skilj offentlig observation från privat åtkomst. Marknadsdatavyn kan fortsätta fungera medan kontoläsningar och orderåtgärder misslyckas. Gränssnittet bör förklara skillnaden så att operatören inte antar att en rörlig prisvisning bevisar att handelsanslutningen fungerar.
Guiden till Kalshis handelsplattform behandlar kontoåtkomst och praktisk användbarhet. Acceptans bör omfatta vad läsaren ser vid autentiseringsfel: berörda behörigheter, senast verifierad kontotid och olösta åtaganden. En allmän märkning som ”frånkopplad” räcker inte om den döljer vilket ansvar som fortfarande kan fullgöras.
Pröva gränssnittet för mänsklig granskning
En bot kan ha korrekta interna poster och ändå vilseleda operatören genom dålig presentation. Pröva om vyn skiljer föreslagna, godkända, inskickade, aktiva, genomförda och avstämda tillstånd. Visa delantal och olösta poster utan att kräva att läsaren tolkar råa loggar.
Be en granskare förklara en påhittad incident enbart utifrån de visade posterna. Granskaren bör identifiera kontraktet, möjlig exponering, senast verifierade belägg och nästa åtgärd. Om det inte går har acceptanssviten hittat ett användbarhetsproblem som kan bli ett driftproblem under press.
Jämförelsen med Polymarkets handelsplattform hjälper till att skilja allmänna gränssnittsansvar från handelsplatsmekanismer. Tydlig information om förvaring, order och avräkning spelar roll i båda sammanhangen, men etiketterna måste beskriva den faktiska kontomodellen. Gemensam visuell utformning bör inte få olika tillstånd att se ekonomiskt identiska ut.
Versionshantera acceptansbeläggen
Spara scenario, klientversion, konfiguration och observerat resultat för varje acceptanskörning. En senare kod- eller schemaändring kan då jämföras med en känd baslinje. Utan versionshanterade belägg kan ett påstående om godkända tester gälla en konfiguration som inte längre används.
Rikta regressionstester mot meningsfulla gränser: belopp, riktning, behörigheter, dubbletthantering och återhämtning. Att upprepa ett lyckat vanligt anslutningstest hundratals gånger tillför lite om en migrering ändrade fältet som avgör om en order köper eller säljer det avsedda utfallet.
Den äldre guiden om handels-API:er för prognosmarknader förklarar anslutning och verifiering som skilda ansvar. Acceptansbelägg bör på samma sätt skilja ett nåbart gränssnitt från att hela kontoflödet beter sig korrekt. Båda är användbara fakta, men bara den ena besvarar de svåra driftfallen.
Ge Kalshi-boten bara den omfattning den klarade
Acceptans är grund för ett avgränsat driftbeslut. En bot som klarar avstämningstester med enbart läsåtkomst har inte automatiskt visat återhämtning av verkliga order. En bot som prövats med en ordertyp har inte nödvändigtvis hanterat varje annan giltighetstid eller kontokonfiguration.
Dokumentera godkänd omfattning, kända begränsningar och villkor som kräver ny granskning. Utökning bör följa nya belägg: ytterligare scenariotäckning, aktuell schemavalidering och en tydlig kontopolicy. Bevara möjligheten att stanna i observationsläge eller övervakat läge när ett återhämtningsfall fortfarande är olöst.
Det mest användbara acceptansresultatet är ett exakt påstående om visat beteende. Det visar att boten bevarar enheter, respekterar befogenheter, behandlar avslut en gång och återskapar kontotillstånd efter angivna fel. Beläggen ger mer information än en bred tillförlitlighetsetikett och en konkret grund för operatörens beslut om vilket arbete programmet får utföra härnäst.