En Kalshi-API-bot bør gøre sig fortjent til sin driftsmæssige rækkevidde gennem demonstreret adfærd. En vellykket forbindelse eller én accepteret ordre viser ikke, hvordan programmet håndterer delvise udførelser, dubletmeddelelser, ændrede markedsbegrænsninger eller et nedbrud efter afsendelse. Disse tilfælde afgør, om dets kontoregistrering forbliver troværdig, når almindelige antagelser svigter.
Acceptkriterier omsætter brede påstande som pålidelig eller sikker til observerbare resultater. De angiver kontoens begyndelsestilstand, den indførte begivenhed, den handling botten må foretage, og de registreringer, der forventes bagefter. En test, der ikke kan angive sit forventede økonomiske resultat, vil næppe fastslå meget om bottens adfærd.
Denne vejledning præsenterer hypotetiske acceptøvelser til en bemyndiget udviklingsproces. Numeriske grænser og priser er opdigtede. Demotest, simulerede svar og genafspillede registreringer kan vurdere softwareadfærd uden at bevise produktionslikviditet eller strategirentabilitet. Enhver faktisk handelsbemyndigelse er fortsat en separat beslutning afgrænset af kontoejerens instruktioner.
Skriv først acceptkriterier for Kalshi-API-botten
Acceptkriterier for en Kalshi-bot bør beskrive udfald før implementeringsdetaljer. Genafspilning af den samme udførelse to gange skal eksempelvis efterlade positionen ændret én gang. Et udløbet forslag må ikke blive til en ny ordre. Et mistet svar skal skabe en uafklaret tilstand frem for automatisk at frigive sin reservation.
Angiv den dokumentation, der kræves for at bestå. En konsolmeddelelse om dublet ignoreret er ikke nok, hvis regnskabet stadig talte mængden to gange. Undersøg den resulterende position, gebyrer, ordrestatus og journal. Acceptresultatet bør være forståeligt for en person, der ikke skrev den relevante kode.
Den ældre vejledning om en Kalshi-API-handelsbot i Python beskriver pålideligt design ud over en sprogspecifik klient. Brug dette perspektiv her: den vigtige egenskab er adfærden ved kontogrænsen. Valget af programmeringssprog fjerner ikke behovet for at verificere økonomisk betydning.
Fastlæg en kendt begyndelsestilstand for kontoen
Hver øvelse kræver en begyndelsestilstand, der kan kontrolleres uafhængigt. Angiv positioner, aktive ordrer, tilgængelig kapacitet og uafklarede hensigter. Uden et kendt udgangspunkt kan en senere uoverensstemmelse tilskrives et uforklaret tidligere forhold frem for den adfærd, der testes.
Begynd for en hypotetisk testsamling med ti Ja-kontrakter, en aktiv ordre på fem kontrakter og en begivenhedsgrænse på tredive kontrakter. Botten bør beregne femten kontrakter i eksisterende eller mulig eksponering under denne enkle politik. En ny anmodning om tyve ville overskride grænsen, hvis alle mængder blev til positioner.
Hold disse testdata adskilt fra faktiske kontooplysninger. En test bør aldrig lydløst låne produktionslegitimationsoplysninger eller udlede, at en velkendt markedsidentifikator er harmløs. Identificer miljøet klart, og brug de kontroller, der passer til det. Formålet er at teste en afgrænset adfærd frem for at opdage kontoens tilstand gennem utilsigtet udførelse.
Test præcise decimalbeløb
Aktuel Kalshi-dokumentation bruger priser og mængder med fast decimalpræcision. Accept bør omfatte værdier, som en parser til hele cents eller hele kontrakter ville håndtere forkert, og samtidig respektere de hypotetiske markedsbegrænsninger, øvelsen bruger.
Brug en opdigtet gyldig pris på 0,3375 dollar og en mængde på 8,40 kontrakter. Deres købsværdi er 2,835 dollar før gebyrer. Det forventede regnskab bør bevare det præcise produkt på det stadie, hvor det er meningsfuldt, og derefter anvende eventuelle dokumenterede endelige afrundingsregler separat. At afkorte mængden til otte er en fejl.
Test også ugyldige formater, manglende enheder og værdier uden for tilladte intervaller. Botten bør afvise eller isolere en tvetydig mængde eller et tvetydigt beløb frem for at gætte. En parser, der accepterer fejlformede værdier, fordi den kan udtrække nogle cifre, skaber en farlig forskel mellem det, inputtet siger, og det, kontoen kan gøre.
Test prisgitteret uafhængigt af præcision
En decimalværdi kan være syntaktisk gyldig, men ligge uden for markedets tilladte gitter. Botten bør læse aktuelle prisbegrænsninger og verificere den foreslåede limit mod dem. En streng med fire decimaler er ikke automatisk en gyldig pris med fire decimaler for ethvert marked.
I et hypotetisk interval med trin på 0,005 dollar ligger en tilsigtet maksimal købspris på 0,3375 dollar mellem 0,335 og 0,340 dollar. Hvis politikken afrunder til en tilladt købspris, må den ikke overskride det godkendte maksimum. Afrunding opad til 0,340 dollar ville bryde denne bestemte instruktion.
Test en gitterændring mellem oprettelse af forslaget og indsendelse. Den forventede adfærd bør være en ny validering, en bemyndiget tilpasning eller en afvisning til gennemgang. Botten bør ikke gentagne gange indsende en ugyldig pris og samtidig antage, at enhver afvisning er et midlertidigt netværksproblem.
Test økonomisk retning med tilfælde i almindeligt sprog
En ordreadapter bør korrekt omsætte brugerens tilsigtede udfaldseksponering til det aktuelle slutpunkts retningsfelter. Kalshis dokumentation om ordreretning er referencen til fortolkning af aktuelle svarfelter. Anmodningssemantik bør også kontrolleres mod det præcise slutpunkt, der bruges.
Skriv tilfælde i menneskelige termer, før serialiserede data undersøges: øg Ja-eksponering ved en maksimal pris, reducer en eksisterende position ved en minimal pris, eller udtryk en understøttet beslutning på Nej-siden gennem det aktuelle interface. Afkod hver anmodning tilbage til almindeligt sprog, og sammenlign den med den oprindelige hensigt.
Medtag tilfælde med komplementære priser, fordi de kan skjule fejl. En numerisk plausibel værdi på den forkerte side kan give gyldig, men utilsigtet eksponering. At bestå en skemavalidering beviser kun, at anmodningen har en acceptabel form; accept skal også bevise, at formen bærer den tilsigtede økonomiske instruktion.
Test tilladelsesgrænsen
Giv botten tilladelse til at observere en bred markedsliste, men kun handle en lille godkendt delmængde. Præsenter derefter et attraktivt forslag uden for denne delmængde. Det forventede resultat er en registreret afvisning uden nogen signeret eller sendt ordre.
Gentag øvelsen med en ordretype, der ikke understøttes, en for stor mængde og en udløbet bemyndigelse. Hver bør fejle ved den passende kontrol. En modelgenereret forklaring bør ikke kunne tilsidesætte politikken ved at bruge presserende sprog eller hævde usædvanligt høj sikkerhed.
Vejledningen om Polymarket-automatisering sammenligner manuelle, overvågede og delegerede arbejdsgange. Dens nyttige generelle lære er, at bemyndigelse skal være eksplicit på hvert stadie. For denne Kalshi-bot bør acceptregistreringen vise præcis, hvilken handling der blev nægtet, og hvilket observations- eller afstemningsarbejde der stadig var tilladt.
Test samtidige forslag mod én grænse
To forslag kan bestå individuelt og samtidig overskride en fælles grænse sammen. Accept bør indføre dem tæt nok på hinanden i tid til at afsløre et kapløb mellem kapacitetskontrol og registrering af reservationer. Den forventede adfærd er koordineret bemyndigelse frem for to uafhængige godkendelser baseret på det samme forældede øjebliksbillede.
Vend tilbage til den hypotetiske grænse på tredive kontrakter med femten allerede ejede eller forpligtede. To forslag anmoder hver om ti. Kun én tilføjelse på ti kontrakter passer, hvis politikken vurderer udført mængde i værste tilfælde; det andet ville hæve mulig eksponering til femogtredive. Botten skal afvise, ændre størrelse under en bemyndiget politik eller udskyde det andet forslag.
Undersøg det fælles regnskab efter begge beslutninger. Det bør indeholde én konsekvent reservationstotal og en grund til det udskudte eller afviste forslag. Testen bør ikke bestå, blot fordi en senere afvisning fra handelsstedet tilfældigvis forhindrede overskridelsen. Applikationens egen bemyndigelsesgrænse skal virke.
Test idempotent behandling af udførelser
Idempotent behandling af udførelser betyder, at modtagelse af den samme økonomiske udførelse mere end én gang har den samme kontovirkning som modtagelse én gang. Strømme, genforbindelser og senere kontoforespørgsler kan alle levere overlappende dokumentation. Botten skal genkende den samme udførelse gennem dens stabile identitet og dokumenterede revisionssemantik.
Begynd med ti kontrakter, og indfør en udførelse på fire kontrakter. Den resulterende position er fjorten. Genafspil den samme udførelse gennem en anden vej; resultatet bør forblive fjorten med det tilhørende gebyr registreret én gang. En anden, særskilt udførelse på fire kontrakter bør derefter give atten.
Denne test adskiller dublettransport fra gentagen legitim handel. Dubletfjernelse alene ud fra mængde og pris ville forkert kassere separate udførelser, der tilfældigvis har identiske vilkår. Registreringen kræver identifikatorer og oprindelsesinformation, der er stærk nok til at bevare reelle udførelser og undertrykke gentagne observationer af den samme.
Test delvise udførelser og reststatus
En delvis udførelse bør opdatere beholdninger med den udførte mængde og bevare den korrekte tilstand for den uudførte del. Den valgte gyldighedsadfærd betyder noget. En hvilende rest og en annulleret øjeblikkelig rest er forskellige kontoforpligtelser, selv når den udførte mængde er identisk.
I en hypotetisk ordre på tolv kontrakter udføres fem til 0,40 dollar, hvilket koster 2 dollar før gebyrer. Syv forbliver uudførte. Én øvelse lader disse syv være aktive; en anden afslutter dem under den valgte dokumenterede adfærd for øjeblikkelige ordrer. De forventede reservations- og ordrepaneler bør derfor være forskellige.
Botten bør aldrig udlede, at enhver delvis udførelse skaber en aktiv rest. Den bør også undgå at behandle en annulleret rest som annullering af de udførte fem. Kontroller position, købsomkostning, gebyrer og endelig ordrestatus sammen, så testen verificerer det komplette økonomiske resultat.
Henvis og tjen USDC
Henvis og tjen USDCVores affiliateprogram udbetaler i realtid.
Test et mistet indsendelsessvar
Simuler afsendelse af en ordre efterfulgt af tab af svaret. I ét tilfælde accepterede handelsstedet den; i et andet afviste det den. Botten har indledningsvis det samme lokale symptom, så dens første reaktion bør bevare usikkerhed og undersøge den oprindelige hensigt.
Den forventede adfærd omfatter at bevare den relevante reservation, undgå en ny ordre uden forbindelse til det oprindelige forsøg og undersøge understøttede ordre- og udførelsesregistreringer. Testen bør verificere, at en tom liste over åbne ordrer ikke i sig selv afslutter sagen, hvis ordren kan være udført fuldt ud.
En klientordreidentifikator kan hjælpe med at forbinde registreringer, men botten skal verificere handelsstedets aktuelle dublethåndteringssemantik frem for at antage ubegrænset udførelse præcis én gang. Lokal idempotent behandling, anmodningsidentitet og garantier for ekstern accept er relaterede værktøjer med forskellige rækkevidder. Acceptkriterierne bør angive, hvilken garanti der faktisk testes.
Test et nedbrud efter accept
En særligt nyttig øvelse i genopretning efter genstart stopper processen, efter at handelsstedet accepterer en ordre, men før den lokale succesregistrering gemmes. Ved genstart bør botten indlæse sin varige hensigt og afstemme den eksterne tilstand, før den beslutter, om noget skal sendes.
Hvis den blot genafspiller enhver hensigt uden et lokalt fuldførelsesflag, kan den skabe dobbelt eksponering. Det forventede genopretningsresultat er én økonomisk ordre forbundet med den oprindelige hensigt med enhver aktiv mængde eller udførelse afspejlet i kontoregnskabet. Hvis den tilgængelige dokumentation ikke kan fastslå forholdet, bør resultatet forblive eksplicit uafklaret.
Den ældre vejledning om en automatisk handelsbot til Kalshi forklarer driftstilstande. Genstart bør være en overgang gennem observation og afstemning frem for et automatisk spring til ubegrænset handel. Accept bør undersøge denne overgang frem for kun at bekræfte, at processen starter med succes.
Test annullering under en udførelse
Indfør en udførelse, mens en annullering er i gang. Botten bør afstemme den udførte mængde og den del, der faktisk blev fjernet. En annulleringsanmodning udtrykker hensigt; den forhindrer ikke med tilbagevirkende kraft en udførelse, der allerede skete.
Antag for en opdigtet aktiv rest på ni kontrakter, at tre udføres, før annullering fjerner de andre seks. Kontopositionen stiger med tre, og forpligtelsen knyttet til seks slutter. Et erstatningsforslag bør bruge denne resulterende tilstand frem for at antage, at alle ni blev annulleret.
Kontroller operatørforklaringen såvel som tallene. Interfacet bør vise, hvorfor den endelige position adskiller sig fra den mængde, der var synlig, da annullering begyndte. En generisk annulleret betegnelse kan skjule den yderligere udførelse og tilskynde til en for stor erstatning, selv hvis det underliggende regnskab tilfældigvis indeholder den korrekte mængde.
Test ændret markedstilstand
Et forslag kan være gyldigt, når det skabes, og ugyldigt, når det når indsendelse. Indfør en pause, lukning eller ændret markedsbegrænsning mellem disse stadier. Den forventede adfærd bør følge aktuelle handelsstedsregler og applikationens politik uden forsøg på at omgå tilstanden gennem gentagne anmodninger.
Kalshis dokumentation om markedets livsforløb beskriver de aktuelle handels- og afregningsstadier. Acceptsamlingen bør bruge denne semantik frem for at antage, at ét generisk åben-eller-lukket-flag dækker ethvert ansvar.
Forskning kan fortsætte, mens ordreoprettelse er deaktiveret, og afstemning kan fortsat være nødvendig efter handelens afslutning. Test disse funktioner separat. En bot, der stopper al kontoobservation, når et marked lukker, kan overse netop de registreringer, der kræves for at fastslå endelige positioner, gebyrer og afregning. Driftsbegrænsninger bør indsnævre handlinger uden at slette pligten til at redegøre for tidligere handlinger.
Test strømhuller og overlappende genopretningslæsninger
Afbryd den private strøm, mens udførelser sker, og forbind derefter igen og hent kontohistorik. Genopretningsprocessen kan møde både udførelser, der allerede var set før hullet, og nye udførelser. Det forventede regnskab bør medtage hver økonomisk begivenhed én gang og identificere det gendannede interval.
En nyttig øvelse returnerer registreringer i en ubekvem rækkefølge. En sen opdatering bør ikke overskrive en nyere tilstand, blot fordi den kom senere lokalt. Bevar begivenhedsidentifikatorer, relevante tidsstempler og dokumenterede versionsoplysninger, når det afgøres, hvordan registreringer hænger sammen.
Hvis komplet dækning ikke kan fastslås, bør botten bevare en undtagelse og begrænse ny eksponering under sin politik. En position, der ser præcis ud, men er udledt fra en ufuldstændig strøm, er ikke en vellykket genopretning. Testen består, når resultatet enten er verificeret eller ærligt uafklaret med et klart næste skridt.
Test hastighedsgrænser uden at ændre hensigt
En hastighedsbegrænset læsning eller skrivning bør ikke få botten til at ændre anmodningens økonomiske betydning. Ventetid mellem forsøg kan ændre timingen, men må ikke lydløst øge mængde, udvide en limit eller skabe en ny uafhængig hensigt. Forsinkede forslag kan udløbe, mens de venter.
Afprøv både rutinemæssig begrænsning af markedsdata og en privat afstemningsanmodning, der kræves for at afklare usikkerhed. Botten bør prioritere efter sin driftspolitik og bevare tilstrækkelig kapacitet til væsentlig kontoobservation, hvor interfacet tillader det. Den bør ikke bruge enhver tilgængelig anmodning på prisopdateringer med lav værdi.
Registrer den faktiske forsinkelse i forsknings- og udførelseshistorikken. En strategi kan ikke hævde det oprindelige pristilbud, hvis hastighedsbegrænsning udskød dens beslutning. Acceptresultatet bør vise, at forældede forslag blev genvalideret eller afvist, og at uafklarede indsendelser fortsat var knyttet til deres oprindelige reservationer.
Test legitimationsfejl som en kontrolleret tilstand
Udløbne, tilbagekaldte eller fejlkonfigurerede legitimationsoplysninger bør give en klar tilstand med tab af funktioner. Botten bør undgå at eksponere hemmeligheder i fejlmeddelelser og bør ikke falde tilbage til en utilsigtet konto eller et utilsigtet miljø blot for at få anmodningen til at lykkes.
Skeln mellem offentlig observation og privat adgang. Markedsdataskærmen kan fortsætte med at virke, mens kontolæsninger og ordrehandlinger fejler. Interfacet bør forklare forskellen, så operatøren ikke udleder, at en bevægelig prisvisning beviser, at handelsforbindelsen er sund.
Vejledningen om en handelsplatform til Kalshi gennemgår kontoadgang og driftsmæssig brugbarhed. Accept bør omfatte det, en læser ser under legitimationsfejl: de berørte tilladelser, det sidst verificerede kontotidspunkt og uafklarede forpligtelser. Et generisk afkoblet mærke er utilstrækkeligt, hvis det skjuler, hvilke ansvar der stadig kan fuldføres.
Test fladen til menneskelig gennemgang
En bot kan bevare korrekte interne registreringer og stadig vildlede sin operatør gennem dårlig præsentation. Test, om skærmen skelner mellem foreslåede, bemyndigede, indsendte, aktive, udførte og afstemte tilstande. Vis delvise mængder og uafklarede elementer uden at kræve, at læseren fortolker rå logfiler.
Bed en gennemlæser forklare en opdigtet hændelse alene ud fra den viste registrering. Vedkommende bør identificere kontrakten, mulig eksponering, sidst verificerede dokumentation og næste handling. Hvis det ikke er muligt, har acceptsamlingen fundet et brugbarhedsproblem, der kan blive et driftsproblem under pres.
Sammenligningen med en handelsplatform til Polymarket hjælper med at adskille generelle interfaceansvar fra handelsstedsmekanik. Klare oplysninger om opbevaring, ordrer og afregning betyder noget i begge kontekster, men betegnelserne skal beskrive den faktiske kontomodel. Et fælles visuelt design bør ikke få uens tilstande til at se økonomisk identiske ud.
Versionsstyr acceptdokumentation
Gem scenariet, klientversionen, konfigurationen og det observerede resultat for hver acceptkørsel. En senere kode- eller skemaændring kan da sammenlignes med et kendt udgangspunkt. Uden versionsstyret dokumentation kan en påstand om, at botten bestod test, vedrøre en konfiguration, der ikke længere bruges.
Fokuser regressionskontroller på meningsfulde grænser: mængder og beløb, retning, tilladelser, dubletbehandling og genopretning. Gentagelse af en vellykket almindelig forbindelsestest hundredvis af gange tilføjer lidt, hvis en migrering ændrede det felt, der afgør, om en ordre køber eller sælger det tilsigtede udfald.
Den ældre vejledning om et handels-API til forudsigelsesmarkeder forklarer forbindelse og verificering som forskellige ansvar. Acceptdokumentation bør ligeledes skelne mellem, at et interface kan nås, og at den komplette kontoarbejdsgang opfører sig korrekt. Begge er nyttige forhold, men kun det ene behandler de vanskelige driftstilfælde.
Giv kun Kalshi-API-botten den rækkevidde, den bestod
Accept er et grundlag for en afgrænset driftsbeslutning. En bot, der består afstemningstest med kun læseadgang, har ikke automatisk demonstreret genopretning af faktiske ordrer. En bot testet på én ordretype har ikke nødvendigvis håndteret enhver anden levetid eller kontokonfiguration.
Dokumenter den godkendte rækkevidde, kendte begrænsninger og betingelser, der kræver en ny gennemgang. Udvidelse bør følge ny dokumentation: yderligere scenariedækning, validering af aktuelt skema og en klar kontopolitik. Bevar muligheden for at forblive i observations- eller overvåget tilstand, når et genopretningstilfælde stadig er uafklaret.
Det mest nyttige acceptresultat er et præcist udsagn om demonstreret adfærd. Det viser, at botten bevarer enheder, respekterer bemyndigelse, behandler udførelser én gang og rekonstruerer kontotilstand efter angivne fejl. Denne dokumentation er mere informativ end en bred pålidelighedsbetegnelse og giver operatøren et konkret grundlag for at afgøre, hvilket arbejde programmet må udføre bagefter.