En Kalshi-API-bot bør fortjene driftsomfanget gjennom demonstrert atferd. En vellykket forbindelse eller én akseptert ordre viser ikke hvordan programmet håndterer delvise utførelser, duplikatmeldinger, endrede markedsbegrensninger eller et krasj etter overføring. Tilfellene avgjør om kontoregistreringen forblir pålitelig når vanlige forutsetninger svikter.
Akseptansekriterier oversetter brede påstander som pålitelig eller trygg til observerbare resultater. De angir kontoens starttilstand, hendelsen som innføres, handlingen boten kan utføre og registreringene som forventes etterpå. En test som ikke kan oppgi forventet økonomisk resultat, vil neppe fastslå mye om botens atferd.
Denne veiledningen presenterer hypotetiske akseptanseøvelser for en autorisert utviklingsprosess. Tallgrenser og priser er oppdiktede. Demotesting, simulerte svar og avspilte registreringer kan evaluere programvareatferd uten å bevise produksjonslikviditet eller strategilønnsomhet. Enhver reell handelsfullmakt er fortsatt en separat beslutning avgrenset av kontoeierens instrukser.
Skriv akseptansekriteriene for Kalshi-API-boten først
Akseptansekriterier for en Kalshi-bot bør beskrive utfall før implementasjonsdetaljer. For eksempel må avspilling av samme utførelse to ganger endre posisjonen én gang. Et utløpt forslag må ikke bli en ny ordre. Et tapt svar må skape en uavklart tilstand fremfor automatisk å frigjøre reservasjonen.
Oppgi dokumentasjonen som kreves for å bestå. En konsollmelding som sier «duplikat ignorert», er ikke nok hvis regnskapet fortsatt telte mengden dobbelt. Undersøk resulterende posisjon, gebyrer, ordretilstand og journal. Akseptanseresultatet bør være forståelig for noen som ikke skrev den relevante koden.
Den eldre veiledningen om en Python-handelsbot for Kalshi-API-et beskriver pålitelig design utover en språkspesifikk klient. Bruk perspektivet her: den viktige egenskapen er atferden ved kontogrensen. Valg av programmeringsspråk fjerner ikke behovet for å kontrollere økonomisk betydning.
Fastsett en kjent starttilstand for kontoen
Hver øvelse trenger en starttilstand som kan kontrolleres uavhengig. Angi posisjoner, aktive ordrer, tilgjengelig kapasitet og uavklarte hensikter. Uten en kjent referanse kan et senere avvik tilskrives en uforklart tidligere tilstand fremfor atferden som testes.
For en hypotetisk testpakke begynner vi med ti Ja-kontrakter, en aktiv ordre på fem kontrakter og en hendelsesgrense på tretti kontrakter. Boten bør beregne femten kontrakter i eksisterende eller mulig eksponering etter den enkle regelen. En ny forespørsel på tjue ville overstige grensen hvis alle mengder ble posisjoner.
Hold testdataene adskilt fra aktive kontodata. En test bør aldri stille låne produksjonslegitimasjon eller utlede at en kjent markedsidentifikator er ufarlig. Identifiser miljøet tydelig og bruk passende kontroller. Formålet er å teste avgrenset atferd, ikke å oppdage kontotilstanden gjennom utilsiktet gjennomføring.
Test nøyaktige desimalbeløp
Gjeldende Kalshi-dokumentasjon bruker fastpunktpriser og -mengder. Akseptanse bør inkludere verdier som en parser for hele cent eller hele kontrakter ville håndtert feil, samtidig som de hypotetiske markedsbegrensningene i øvelsen respekteres.
Bruk en oppdiktet gyldig pris på $0,3375 og mengde på 8,40 kontrakter. Kjøpsverdien er $2,835 før gebyrer. Forventet regnskap bør bevare nøyaktig produkt på trinnet der det er meningsfullt, og deretter bruke dokumenterte sluttavrundingsregler separat. Avkorting av mengde til åtte er en feil.
Test også ugyldige formater, manglende enheter og verdier utenfor tillatte områder. Boten bør avvise eller sette et tvetydig beløp i karantene fremfor å gjette. En parser som aksepterer feilformede verdier fordi den kan hente ut noen sifre, skaper en farlig forskjell mellom det inndataene sier, og det kontoen kan gjøre.
Test prisrutenettet uavhengig av presisjon
En desimalverdi kan være syntaktisk gyldig, men utenfor markedets tillatte rutenett. Boten bør lese gjeldende prisbegrensninger og kontrollere foreslått limit mot dem. En streng med fire desimaler er ikke automatisk en gyldig pris med fire desimaler for hvert marked.
I et hypotetisk bånd med intervaller på $0,005 ligger en tiltenkt maksimal kjøpspris på $0,3375 mellom $0,335 og $0,340. Hvis regelen avrunder til en tillatt kjøpspris, må den ikke overstige godkjent maksimum. Avrunding opp til $0,340 ville bryte akkurat den instruksen.
Test en rutenettendring mellom forslagsopprettelse og innsending. Forventet atferd bør være ny validering, en godkjent justering eller avslag for gjennomgang. Boten bør ikke gjentatte ganger sende en ugyldig pris mens den antar at hvert avslag er et midlertidig nettverksproblem.
Test økonomisk retning med tilfeller i vanlig språk
En ordreadapter bør oversette brukerens tiltenkte utfallseksponering riktig til gjeldende endepunkts retningsfelt. Kalshis dokumentasjon for ordreretning er referansen for tolkning av gjeldende svarfelt. Forespørselssemantikk bør også kontrolleres mot det nøyaktige endepunktet som brukes.
Skriv tilfeller i menneskelige begreper før serialiserte data undersøkes: øke Ja-eksponering til en maksimalpris, redusere en eksisterende posisjon til en minstepris eller uttrykke en støttet Nei-sidebeslutning gjennom gjeldende grensesnitt. Dekod hver forespørsel tilbake til vanlig språk og sammenlign med opprinnelig hensikt.
Inkluder komplementære pristilfeller fordi de kan skjule feil. En tallmessig plausibel verdi på feil side kan gi gyldig, men utilsiktet eksponering. Å bestå en skjemavalidator beviser bare at forespørselen har akseptabel form; akseptanse må også bevise at formen bærer tiltenkt økonomisk instruks.
Test tillatelsesgrensen
Gi boten tillatelse til å observere en bred markedsliste, men bare handle et lite godkjent delsett. Presenter så et attraktivt forslag utenfor delsettet. Forventet resultat er et registrert avslag uten noen signert eller overført ordre.
Gjenta øvelsen med en ordretype som ikke støttes, en for stor mengde og en utløpt godkjenning. Hver bør stoppes ved riktig kontroll. En modellgenerert forklaring bør ikke kunne overstyre reglene med akutt språk eller påstander om uvanlig høy sikkerhet.
Veiledningen om Polymarket-automatisering sammenligner manuelle, overvåkede og delegerte arbeidsflyter. Den nyttige generelle lærdommen er at fullmakt må være uttrykkelig på hvert trinn. For denne Kalshi-boten bør akseptanseregistreringen vise nøyaktig hvilken handling som ble nektet, og hvilket observasjons- eller avstemmingsarbeid som fortsatt var tillatt.
Test samtidige forslag mot én grense
To forslag kan bestå hver for seg og samtidig overskride en delt grense sammen. Akseptanse bør innføre dem tett nok i tid til å avdekke et kappløp mellom kapasitetskontroll og registrering av reservasjoner. Forventet atferd er samordnet godkjenning, ikke to uavhengige godkjenninger basert på samme foreldede øyeblikksbilde.
Gå tilbake til den hypotetiske grensen på tretti kontrakter med femten allerede holdt eller bundet. To forslag ber hver om ti. Bare ett tillegg på ti kontrakter passer hvis regelen vurderer verstefallet for utført mengde; det andre ville øke mulig eksponering til trettifem. Boten må avslå, endre størrelse etter godkjente regler eller utsette andre forslag.
Undersøk det delte regnskapet etter begge beslutninger. Det bør inneholde én konsekvent reservasjonssum og en grunn til utsatt eller avslått forslag. Testen bør ikke bestå bare fordi et senere handelsplassavslag tilfeldigvis hindret overskridelsen. Applikasjonens egen godkjenningsgrense må virke.
Test idempotent behandling av utførelser
Idempotent behandling av utførelser betyr at mottak av samme økonomiske utførelse mer enn én gang har samme kontovirkning som mottak én gang. Strømmer, gjenoppkoblinger og senere kontospørringer kan alle levere overlappende dokumentasjon. Boten må gjenkjenne samme utførelse gjennom stabil identitet og dokumentert revisjonssemantikk.
Start med ti kontrakter og innfør en utførelse på fire kontrakter. Resulterende posisjon er fjorten. Spill av samme utførelse gjennom en annen vei; resultatet bør forbli fjorten med tilknyttet gebyr registrert én gang. En andre, egen utførelse på fire kontrakter bør deretter gi atten.
Testen skiller duplikattransport fra gjentatt legitim handel. Duplikatfjerning bare etter mengde og pris ville feilaktig forkaste separate utførelser som tilfeldigvis har identiske vilkår. Registreringen trenger identifikatorer og proveniens sterke nok til å bevare reelle gjennomføringer og samtidig undertrykke gjentatte observasjoner av samme utførelse.
Test delvise utførelser og resttilstand
En delvis utførelse bør oppdatere beholdninger med utført mengde og bevare riktig tilstand for uutført del. Valgt varighetsatferd betyr noe. En hvilende rest og en kansellert umiddelbar rest er forskjellige kontoforpliktelser selv når utført mengde er identisk.
I en hypotetisk ordre på tolv kontrakter utføres fem til $0,40, som koster $2 før gebyrer. Sju forblir uutført. Én øvelse lar de sju forbli aktive; en annen avslutter dem etter valgt dokumentert umiddelbar ordreatferd. Forventet reservasjons- og ordrevisning bør være forskjellig deretter.
Boten bør aldri utlede at hver delvis utførelse skaper en aktiv rest. Den bør også unngå å behandle en kansellert rest som kansellering av de utførte fem. Kontroller posisjon, kjøpskostnad, gebyrer og endelig ordretilstand sammen slik at testen kontrollerer hele det økonomiske resultatet.
Henvis og tjen USDC
Henvis og tjen USDCPartnerprogrammet vårt betaler i sanntid.
Test et tapt innsendingssvar
Simuler overføring av en ordre fulgt av tap av svaret. I ett tilfelle aksepterte handelsplassen den; i et annet avslo den. Boten har først samme lokale symptom, så første respons bør bevare usikkerhet og undersøke opprinnelig hensikt.
Forventet atferd inkluderer å bevare relevant reservasjon, unngå en ny ubeslektet ordre og konsultere støttede ordre- og utførelsesregistreringer. Testen bør kontrollere at en tom liste over åpne ordrer ikke i seg selv lukker saken hvis ordren kan ha blitt fullt utført.
En klientordreidentifikator kan hjelpe til med å knytte registreringer sammen, men boten må kontrollere gjeldende duplikathåndteringssemantikk fremfor å anta ubegrenset nøyaktig én gangs gjennomføring. Lokal idempotent behandling, forespørselsidentitet og eksterne akseptgarantier er beslektede verktøy med ulike omfang. Akseptansekriteriene bør oppgi hvilken garanti som faktisk testes.
Test et krasj etter aksept
En særlig nyttig omstartsgjenopprettingsøvelse stopper prosessen etter at handelsplassen aksepterer en ordre, men før lokal suksessregistrering lagres. Ved omstart bør boten laste den varige hensikten og avstemme ekstern tilstand før den avgjør om noe må sendes.
Hvis den bare spiller av hver hensikt uten et lokalt fullføringsflagg, kan den skape dobbel eksponering. Forventet gjenopprettingsresultat er én økonomisk ordre knyttet til opprinnelig hensikt, med aktiv mengde eller gjennomføring gjenspeilet i kontoregnskapet. Hvis tilgjengelig dokumentasjon ikke kan fastslå forholdet, bør resultatet forbli uttrykkelig uavklart.
Den eldre veiledningen om en automatisk handelsbot for Kalshi forklarer driftstilstander. Omstart bør være en overgang gjennom observasjon og avstemming, ikke et automatisk hopp til ubegrenset handel. Akseptanse bør undersøke overgangen fremfor bare å bekrefte at prosessen starter uten feil.
Test kansellering under en utførelse
Innfør en utførelse mens kansellering pågår. Boten bør avstemme utført beløp og delen som faktisk ble fjernet. En kanselleringsforespørsel uttrykker hensikt; den hindrer ikke i ettertid en utførelse som allerede skjedde.
For en oppdiktet aktiv rest på ni kontrakter antar vi at tre utføres før kansellering fjerner de andre seks. Kontoposisjonen øker med tre, og forpliktelsen knyttet til seks ender. Et erstatningsforslag bør bruke resulterende tilstand fremfor å anta at alle ni ble kansellert.
Kontroller operatørforklaringen så vel som tallene. Grensesnittet bør vise hvorfor endelig posisjon avviker fra mengden synlig da kansellering begynte. En generisk kansellert-etikett kan skjule ekstrautførelsen og oppmuntre til en for stor erstatning selv om underliggende regnskap tilfeldigvis inneholder riktig mengde.
Test endret markedstilstand
Et forslag kan være gyldig ved opprettelse og ugyldig når det når innsending. Innfør en pause, stenging eller endret markedsbegrensning mellom trinnene. Forventet atferd bør følge gjeldende handelsplassregler og applikasjonsregler uten forsøk på å omgå tilstanden med gjentatte forespørsler.
Kalshis dokumentasjon for markedslivsløpet beskriver gjeldende handels- og oppgjørstrinn. Akseptansepakken bør bruke semantikken fremfor å anta at ett generisk åpent-eller-stengt-flagg dekker hvert ansvar.
Forskning kan fortsette mens ordreopprettelse er deaktivert, og avstemming kan fortsatt være nødvendig etter at handel ender. Test evnene separat. En bot som stopper all kontoobservasjon når et marked stenger, kan gå glipp av akkurat registreringene som trengs for å fastslå sluttposisjoner, gebyrer og oppgjør. Driftsrestriksjoner bør snevre inn handlinger uten å slette plikten til å gjøre rede for tidligere handlinger.
Test strømgap og overlappende gjenopprettingslesinger
Koble fra den private strømmen mens utførelser skjer, og koble så til igjen og hent kontohistorikk. Gjenopprettingsprosessen kan møte utførelser allerede sett før gapet så vel som nye. Forventet regnskap bør inkludere hver økonomisk hendelse én gang og identifisere det gjenopprettede intervallet.
En nyttig øvelse returnerer registreringer i en upraktisk rekkefølge. En sen oppdatering bør ikke overskrive en nyere tilstand bare fordi den kom senere lokalt. Bevar hendelsesidentifikatorer, relevante tidsstempler og dokumentert versjonsinformasjon når forhold mellom registreringer avgjøres.
Hvis fullstendig dekning ikke kan fastslås, bør boten beholde et unntak og begrense ny eksponering etter reglene. En presis posisjon utledet fra en ufullstendig strøm er ikke en vellykket gjenoppretting. Testen består når resultatet enten er kontrollert eller ærlig uavklart, med et tydelig neste steg.
Test frekvensgrenser uten å endre hensikt
En frekvensbegrenset lesing eller skriving bør ikke få boten til å endre forespørselens økonomiske betydning. Venting mellom nye forsøk kan endre timing, men må ikke stille øke mengde, utvide en limit eller skape en ny uavhengig hensikt. Forsinkede forslag kan utløpe mens de venter.
Prøv både rutinemessig begrensning av markedsdata og en privat avstemmingsforespørsel som trengs for å avklare usikkerhet. Boten bør prioritere etter driftsreglene og bevare nok kapasitet til viktig kontoobservasjon der grensesnittet tillater det. Den bør ikke bruke hver tilgjengelige forespørsel på budoppdateringer med lav verdi.
Registrer faktisk forsinkelse i forsknings- og gjennomføringshistorikken. En strategi kan ikke hevde opprinnelig bud hvis frekvensbegrensning utsatte beslutningen. Akseptanseresultatet bør vise at foreldede forslag ble validert på nytt eller avslått, og at uavklarte innsendinger forble knyttet til opprinnelige reservasjoner.
Test legitimasjonssvikt som en kontrollert tilstand
Utløpt, tilbakekalt eller feilkonfigurert legitimasjon bør gi en tydelig tilstand med tapt evne. Boten bør unngå å avsløre hemmeligheter i feilmeldinger og bør ikke falle tilbake på en utilsiktet konto eller et utilsiktet miljø bare for å få forespørselen til å lykkes.
Skill offentlig observasjon fra privat tilgang. Markedsdataskjermen kan fortsette å fungere mens kontolesinger og ordrehandlinger svikter. Grensesnittet bør forklare forskjellen slik at operatøren ikke utleder at en bevegelig prisvisning beviser at handelsforbindelsen er frisk.
Veiledningen om en handelsplattform for Kalshi drøfter kontotilgang og operasjonell brukervennlighet. Akseptanse bør inkludere hva en leser ser under legitimasjonssvikt: berørte tillatelser, sist kontrollert kontotid og uavklarte forpliktelser. Et generisk frakoblet-merke er utilstrekkelig hvis det skjuler hvilke ansvar som fortsatt kan fullføres.
Test grensesnittet for menneskelig gjennomgang
En bot kan holde riktige interne registreringer og likevel villede operatøren gjennom dårlig presentasjon. Test om skjermen skiller foreslåtte, godkjente, innsendte, aktive, utførte og avstemte tilstander. Vis delvise mengder og uavklarte elementer uten å kreve at leseren tolker rålogger.
Be en leser forklare en oppdiktet hendelse fra bare den viste registreringen. Vedkommende bør identifisere kontrakt, mulig eksponering, sist kontrollert dokumentasjon og neste handling. Hvis dette ikke lar seg gjøre, har akseptansepakken funnet et brukervennlighetsproblem som kan bli et driftsproblem under press.
Sammenligningen med en handelsplattform for Polymarket hjelper til med å skille generelle grensesnittansvar fra handelsplassmekanikk. Tydelig informasjon om oppbevaring, ordre og oppgjør betyr noe i begge kontekster, men etikettene må beskrive faktisk kontomodell. Et felles visuelt design bør ikke få ulike tilstander til å virke økonomisk identiske.
Bevar versjonert akseptansedokumentasjon
Lagre scenario, klientversjon, konfigurasjon og observert resultat for hver akseptansekjøring. En senere kode- eller skjemaendring kan da sammenlignes med en kjent referanse. Uten versjonert dokumentasjon kan en påstand om at boten besto testing, vise til en konfigurasjon som ikke lenger brukes.
Fokuser regresjonskontroller på meningsfulle grenser: beløp, retning, tillatelser, duplikatbehandling og gjenoppretting. Gjentakelse av en vellykket vanlig tilkoblingstest hundrevis av ganger tilfører lite hvis en migrering endret feltet som avgjør om en ordre kjøper eller selger tiltenkt utfall.
Den eldre veiledningen om handels-API for prediksjonsmarkeder forklarer tilkobling og kontroll som separate ansvar. Akseptansedokumentasjon bør på samme måte skille mellom at et grensesnitt kan nås, og at hele kontoarbeidsflyten oppfører seg riktig. Begge er nyttige fakta, men bare det ene håndterer de vanskelige driftstilfellene.
Gi Kalshi-API-boten bare omfanget den besto
Akseptanse er grunnlag for en avgrenset driftsbeslutning. En bot som består skrivebeskyttede avstemmingstester, har ikke automatisk demonstrert gjenoppretting av aktive ordrer. En bot testet på én ordretype har ikke nødvendigvis håndtert hver annen levetid eller kontokonfigurasjon.
Dokumenter godkjent omfang, kjente begrensninger og vilkår som krever ny gjennomgang. Utvidelse bør følge ny dokumentasjon: mer scenariodekning, gjeldende skjemavalidering og tydelige kontoregler. Bevar muligheten for å forbli i observasjons- eller overvåket modus når et gjenopprettingstilfelle fortsatt er uavklart.
Det nyttigste akseptanseresultatet er en presis erklæring om demonstrert atferd. Den viser at boten bevarer enheter, respekterer fullmakt, behandler utførelser én gang og rekonstruerer kontotilstand etter angitte feil. Dokumentasjonen er mer informativ enn en bred pålitelighetsetikett og gir operatøren et konkret grunnlag for å avgjøre hvilket arbeid programmet kan utføre videre.