Obchodování přes API Kalshi vyžaduje přesnost v ekonomickém významu i reprezentaci údajů. Cena, množství kontraktů, potvrzení objednávky a zůstatek účtu jsou různé druhy informací. Zacházení s nimi jako se zaměnitelnými čísly může vytvořit integraci, která odesílá platné požadavky, ale rozhoduje nesprávně.
Současná schémata zasluhují zvláštní pozornost. Kalshi dokumentuje dolarové ceny s pevnou řádovou čárkou, zlomková množství kontraktů a cenové mřížky konkrétních trhů. Starší příklady předpokládající celé centy nebo dřívější pole směru objednávky by se neměly používat jako univerzální specifikace. Integrace musí vědět, který koncový bod a verzi odpovědi čte.
Tento článek sleduje vymyšlenou objednávku napříč procesem, aniž poskytuje spustitelný obchodní kód. Ceny, množství a poplatky v příkladu jsou hypotetické. Účelem je vysvětlit, jak se autorizovaný pokyn stává prověřitelným záznamem účtu, včetně případů, kdy výsledek zůstává nejistý a další činnost musí počkat.
Začněte obchodování přes API Kalshi mapou schématu
Mapa schématu zaznamenává význam, jednotku a povolené hodnoty každého pole, které klient používá. Měla by rozlišovat identifikátory trhu, ceny, množství, časové značky a stavové štítky. Je to užitečnější než obecný parser přijímající každé pole se známým názvem.
Pro každý koncový bod určete, zda pole popisuje vstupní pokyn, okamžitou odpověď nebo pozdější záznam účtu. Požadovaný počet není totéž co provedený počet. Průměrná cena plnění není totéž co odeslaný limit. Časová značka může popisovat zpracování požadavku místo podkladové události.
Starší průvodce obchodním API Kalshi vysvětluje výběr vhodného datového rozhraní. Sestavte mapu schématu kolem těchto povinností. Při změně verze by mapa měla odhalit, které výpočty a rozhodnutí závisejí na změněném poli, místo aby účinek zůstal skrytý uvnitř aplikačního kódu.
Čtěte přesně množství a částky objednávek Kalshi s pevnou řádovou čárkou
Dokumentace pevné řádové čárky Kalshi popisuje dolarové řetězce a řetězce zlomkových množství. Množství a částky objednávek Kalshi s pevnou řádovou čárkou by se měly zpracovávat přesnou desetinnou aritmetikou nebo celočíselnou aritmetikou s vhodným měřítkem, přičemž během výpočtu zůstávají zachovány jejich ekonomické jednotky.
Zvažte vymyšlenou cenu 0,4725 $ a množství 12,50 kontraktu. Jejich součin je 5,90625 $ před poplatky. Pokud klient ořízne množství na dvanáct, mění požadovanou pozici. Pokud zaokrouhlí cenu na 0,47 $ před kontrolou cenové mřížky trhu, mění limit pokynu.
Formátování pro obrazovku může používat přehledné zobrazení, ale podkladový záznam by měl zachovávat původní přesnost. Štítek ukazující přibližně 5,91 $ by se neměl stát zdrojem pro rekonstrukci objednávky. Uchovávejte přesná množství a částky pro výpočet a výslovně oddělujte zaokrouhlenou prezentaci od autoritativního ekonomického záznamu.
Ověřujte současnou cenovou mřížku
Počet zobrazených desetinných míst neurčuje, zda je cena platná. Trh může definovat mřížku povolených cen, případně s různými kroky v různých pásmech. Klient by měl přijímat současná omezení trhu, místo aby z formátovací zvyklosti odvozoval univerzální cenový krok.
Předpokládejte, že hypotetický trh povoluje v příslušném rozsahu kroky po 0,005 $. Vypočtený limit 0,4725 $ by do této vymyšlené mřížky nezapadal. Klient musí uplatnit výslovná pravidla: odmítnout návrh k prověření nebo zvolit povolenou cenu, která zůstává v mezích autorizovaného ekonomického limitu.
Na směru zaokrouhlení záleží. Zaokrouhlení maximální nákupní ceny nahoru může překročit schválené náklady, zatímco zaokrouhlení minimální prodejní ceny dolů může přijmout méně, než bylo schváleno. Každá transformace by měla být viditelná před autorizací a měla by být znovu zkontrolována, pokud se před odesláním změní omezení trhu.
Zachovávejte směr napříč verzemi API
Strana výsledku a strana knihy popisují různé aspekty objednávky. Uživatel může uvažovat v pojmech nákupu Ano nebo nákupu Ne, zatímco koncový bod může vyjadřovat pokyny vzhledem k jediné knize Ano. Adaptér musí tyto významy mapovat vědomě.
Současná dokumentace objednávek V2 Kalshi popisuje směry nabídky k nákupu a nabídky k prodeji kotované ze strany Ano. Nekopírujte dřívější pole strany a akce do nového požadavku bez prověření současného významu. Povrchně známé pole může po migraci nést jiný význam.
Používejte lidsky srozumitelné akceptační případy. Pro každý podporovaný pokyn dekódujte navržený požadavek zpět do expozice vůči výsledku a ceny zamýšlené uživatelem. Posuzovatel by měl dokázat ověřit mapování bez mentálního výkladu surových polí. To je zvlášť cenné u rozhodnutí na straně Ne, kde doplňkové ceny mohou způsobit, že nesprávné mapování vypadá číselně věrohodně.
Propojte trh s jeho úplnými pravidly
Identifikátor trhu v API by měl být propojen s uchovaným záznamem pravidel. Program vybírající ticker pouze podle shody klíčových slov může zvolit nesprávné datum, práh nebo zdroj. Jinak správná objednávka by pak vytvořila expozici vůči nesprávné události.
Pro hypotetickou objednávku předpokládejte, že kontrakt vyžaduje, aby jmenovaná měsíční statistika byla při původním zveřejnění nad 75. Zaznamenejte s tímto záměrem dané pravidlo, období pozorování a zvolený výsledek. Podobně pojmenovaný kontrakt používající revidované zveřejnění patří k jinému výzkumnému rozhodnutí.
Průvodce automatizací Kalshi vysvětluje začlenění kontrol stavu události do širšího pracovního postupu. Přiřazení kontraktu by mělo nastat před autorizací objednávky, zatímco současný stav trhu se znovu kontroluje blízko odeslání. Platné výzkumné přiřazení nezaručuje, že trh stále přijímá zamýšlenou operaci.
Určete hranici ověřeného požadavku
Hranice ověřeného požadavku určuje, kde aplikace prokazuje svou identitu obchodnímu místu. Omezujte podpisovou komponentu na požadavky, které je oprávněna podporovat. Výzkumné zápisníky, veřejné přehledové panely a běžné diagnostické protokoly obecně nepotřebují přístup k tajnému podpisovému materiálu.
Průvodce klíči API Kalshi popisuje požadavky podepsané RSA pomocí časové značky, metody a cesty, přičemž parametry dotazu jsou z podepisované cesty vyloučeny. Dodržujte současnou specifikaci přesně; přesné bajty a jednotky časové značky jsou součástí požadavků ověřování.
Platný podpis prokazuje, že požadavek pochází od držitele přihlašovacího údaje. Neprokazuje, že požadovaný obchod odpovídá strategii nebo limitům uživatele. Tyto aplikační kontroly musejí probíhat samostatně. Ověření by mělo být posledním kontrolovaným komunikačním krokem již ověřeného pokynu, nikoli náhradou ekonomické autorizace.
Ověřujte účet a prostředí společně
Demonstrační a produkční prostředí by měla být jasně určena v nastavení i ve stavu zobrazovaném uživateli. Úspěšné ověřené načtení je užitečné pouze tehdy, pochází-li ze zamýšleného prostředí a účtu. Test omylem zaměřený na jiný kontext může vytvořit zavádějící jistotu o připravenosti.
Zobrazujte aktivní prostředí vedle identity účtu, podporovaných oprávnění a času nejnovějšího soukromého načtení. Udržujte změny nastavení auditovatelné. Pokud proces změní přihlašovací údaje nebo prostředí, vyžadujte příslušné kontroly účtu před pokračováním jakéhokoli existujícího obchodního postupu.
Testování v demonstračním kontextu může ověřit zpracování požadavků a chování při obnově, ale neprokazuje produkční likviditu, dostupné ceny ani výkon předpovědí. Oddělujte tato tvrzení. Průvodce botem pro API Kalshi rozvíjí akceptační scénáře hodnotící provozní chování bez zaměňování úspěšného testovacího připojení s ověřenou ekonomickou strategií.
Sestavte úplný záměr objednávky
Záměr objednávky by měl určovat kontrakt, ekonomický směr, množství, cenový limit, dobu platnosti a kontext účtu. Měl by také odkazovat na výzkumný návrh a autorizaci, které jej vytvořily. Uložte záměr před přenosem, aby ztracená odpověď nevymazala důvod možné změny účtu.
Stabilní místní identifikátor záměru je užitečný i tehdy, když obchodní místo podporuje také klientský identifikátor objednávky. Zaznamenávejte oba podle jejich rolí. Nepředpokládejte, že pojmenování požadavku automaticky poskytuje neomezenou ochranu před duplicitami; ověřte současné chování obchodního místa a navrhněte obnovu kolem autoritativních podkladů účtu.
Záměr by měl vypršet, když vyprší jeho odůvodnění nebo autorizace. Opožděný pracovní proces by neměl odeslat starý návrh jen proto, že zůstává ve frontě. Před přenosem zkontrolujte, zda cena, množství, stav trhu a kapacita účtu stále odpovídají schválenému rozhodnutí.
Rozlišujte pozorované a autorizované náklady
Kniha objednávek ukazuje možnou cestu provedení v určitém okamžiku. Limit objednávky určuje povolenou cenu. Mohou tak vzniknout různé součty a účet by měl před odesláním rozumět oběma.
Představte si hypotetický nákup dvaceti kontraktů: osm je nabízeno za 0,46 $ a dvanáct za 0,48 $. Pozorované nákupní náklady jsou 3,68 $ plus 5,76 $, tedy 9,44 $ před poplatky. Limit 0,48 $ pro všech dvacet povoluje nákupní cenu až 9,60 $. Rozdíl je 0,16 $.
Rezervujte kapacitu podle příslušných pravidel účtu včetně poplatků nebo dalších požadovaných množství či částek. Pozorované náklady podle knihy jsou užitečné pro vyhodnocení příležitosti, ale neměly by se zaměňovat za zaručený výsledek provedení. Pokud se kotace změní, typ objednávky a její limit určují, co se může stát dál.
Doporučujte a vydělávejte USDC
Doporučujte a vydělávejte USDCNáš partnerský program vyplácí v reálném čase.
Uchovávejte poplatky ve vlastních záznamech
Poplatky mohou záviset na podmínkách trhu, podrobnostech provedení a pravidlech zaokrouhlování. Klient by neměl předpokládat, že jedna natvrdo zakódovaná sazba platí pro každý kontrakt nebo že zobrazený odhad je konečnou účtovanou částkou. Uchovávejte skutečné záznamy poplatků související s plněními a ověřováním a slaďováním.
Dokumentace zaokrouhlování poplatků Kalshi vysvětluje, proč může přesnost při výpočtech účtu záležet. Praktickým návrhem je zachovávat mezilehlé desetinné hodnoty a používat zdokumentovaná konečná pravidla v odpovídající fázi. Opakované předčasné zaokrouhlování může hromadit rozdíly, které se později obtížně diagnostikují.
Pro vymyšlený příklad dvaceti kontraktů předpokládejte celkový poplatek 0,36 $ čistě pro výuku. Pozorované náklady včetně všeho by byly 9,80 $. Tento údaj by měl být označen za předpoklad, dokud skutečné záznamy provedení nezjistí cenu a poplatky. Výzkumný odhad, rezerva na poplatek a vypořádaná účtovaná částka mohou existovat vedle sebe, aniž jsou považovány za stejné číslo.
Vykládejte odpověď na vytvoření úzce
Odpověď na vytvoření objednávky může hlásit identifikátory a informace o okamžitém plnění nebo zbytku. Vykládejte tato pole podle současné dokumentace koncového bodu. Úspěšná odpověď HTTP automaticky neznamená provedení celého požadovaného množství ani neřeší každou pozdější otázku účtu.
Ukládejte odpověď s jejím časem zpracování a původním záměrem. Pokud hlásí nevyplněný zbytek, určete, zda je tento zbytek aktivní podle zvolené doby platnosti. Pokud hlásí plnění, propojte je s účetní knihou účtu, místo abyste považovali požadované množství za provedené.
Odmítnutý požadavek by si měl zachovat důvod. Neznámý výsledek přenosu by si měl zachovat nejistotu. Tyto stavy zasluhují různé činnosti obnovy. Převod každého místního volání bez úspěchu na odmítnutí zjednodušuje program za cenu ztráty rozlišení, jehož absence nejspíše vytvoří neúmyslnou duplicitní expozici.
Ověřujte a slaďujte částečná množství
Částečné provedení mění účet o vyplněné množství, zatímco nevyplněná část se řídí zdokumentovaným chováním doby platnosti objednávky. Zbývající množství může zůstat aktivní, vypršet nebo být zrušeno podle pokynu a výsledku. Zaznamenávejte oba rozměry.
Předpokládejte, že se vymyšlená objednávka dvaceti kontraktů vyplní osmi za 0,46 $ a dalšími pěti za 0,48 $. Třináct vyplněných kontraktů stojí 3,68 $ plus 2,40 $, tedy 6,08 $ před poplatky. Sedm kontraktů zůstává nevyplněných. Pokud zůstávají aktivní při limitu 0,48 $, jejich potenciální nákupní závazek činí 3,36 $ před příslušnými poplatky.
Pokud je zbývajících sedm zrušeno podle zvoleného chování objednávky, tento budoucí závazek po zjištění stavu končí. Účet stále drží třináct provedených kontraktů. Záznam o zrušení nesmí vymazat jejich náklady ani být vykládán jako důkaz, že celá původní objednávka neměla žádný ekonomický účinek.
Prošetřujte ztracené odpovědi před opětovným odesláním
Síťová chyba po přenosu klientovi neříká, zda obchodní místo požadavek přijalo. Při šetření zachovávejte záměr, identifikátory a rezervaci. Dotazujte se na příslušné záznamy objednávek a plnění prostřednictvím podporovaných rozhraní a uchovávejte případná omezení vrácených podkladů.
Samotný prázdný seznam otevřených objednávek nestačí, protože plně provedená objednávka už nemusí čekat v knize. Stejně tak opožděná soukromá aktualizace může zaostávat za výsledkem okamžitého požadavku. Ověřování a slaďování by mělo používat vhodnou kombinaci současného stavu a historie provedení, místo aby spoléhalo na jediný pohodlný pohled.
Starší průvodce botem pro obchodování přes API Kalshi se soustředí na požadavky, jejichž účinky lze ověřit a sladit se záznamy. Jeho ústřední provozní rozlišení platí i zde: opakování komunikace není novou autorizací znovu nakoupit. Nové ekonomické pokyny by měly počkat, dokud není účinek původní činnosti pochopen nebo výslovně ošetřen podle ohraničených pravidel obnovy.
Ověřujte a slaďujte soukromé proudy s načteními účtu
Aktualizace datového proudu mohou poskytovat včasná pozorování objednávek a plnění. Načtení účtu mohou poskytovat současný stav a historické záznamy potřebné po výpadcích. Odolná integrace používá každé pro jeho zdokumentovaný účel a nepředpokládá, že kterékoli samo poskytuje dokonalou nepřerušovanou účetní knihu.
Po opětovném připojení určete nejistý interval, načtěte příslušné záznamy a odstraňte duplicitní pozorování podle stabilních identifikátorů. Plnění viděné přes proud i pozdější dotaz by mělo k množství a nákladům přispět jednou. Pokud se záznam změní, uchovejte jeho revizi místo přidání jako nesouvisejícího provedení.
Kniha ověřování a slaďování účtu by měla vysvětlovat, které podklady podporují každou pozici a otevřený závazek. Pokud je pokrytí neúplné, ponechte dotčený stav nevyřešený. Zobrazení přesného součtu z neúplných údajů může být zavádějící více než zobrazení ověřeného mezisoučtu s jasnou výjimkou při slaďování.
Zpracovávejte uzavření trhu a vypořádání účtu samostatně
Obchodní stav trhu určuje, které operace jsou nyní dostupné. Určení výsledku a konečné vypořádání nastávají prostřednictvím pozdějších stavů životního cyklu. Uzavřený trh není prostě aktivní trh s nepohodlnou kotací a známý výsledek události není totéž co dokončená výplata účtu.
Klient by měl číst současné informace o životním cyklu a uplatňovat zdokumentovaná pravidla operací. Neopakujte stále operaci, která je pro stav trhu neplatná. Uchovávejte důvod, proč přestala být dostupná, a směrujte zbývající práci na účtu k ověřování a slaďování nebo prověření vypořádání.
Průvodce automatizací Polymarket poskytuje kontrastní kontext účtu pro uvažování o delegovaných pracovních postupech. Obecné oddělení pozorování, pravomoci a ověřování a slaďování zůstává užitečné, ale mechanismy kolaterálu, podepisování a vypořádání musejí zůstat specifické pro obchodní místo. Sdílené rozhraní by tyto rozdíly nemělo operátorovi skrývat.
Používejte knihu ověřování a slaďování účtu
Kniha by měla propojovat počáteční stav, provedené obchody, poplatky, případné převody, otevřené závazky a konečné pozice. Každá změna potřebuje určitelný zdroj. Úprava zůstatku bez vysvětlení může zajistit shodu součtu a současně skrýt skutečnou chybu integrace.
U částečného plnění třinácti kontraktů by měl posuzovatel vidět nákupní náklady 6,08 $, skutečné související poplatky a konečný stav zbytku sedmi kontraktů. Pozdější prodeje nebo vypořádání by se měly objevit jako samostatné změny. Kniha by neměla nahrazovat historii pouze nejnovějším čistým množstvím.
Tento záznam podporuje provozní prověření i výzkumnou analýzu. Strategie může porovnávat očekávané a skutečné provedení, zatímco proces účtu ověřuje, co je drženo a dostupné. Propojení těchto účelů společnými identifikátory brání nekonzistentním součtům mezi výkazem výkonnosti a obrazovkou používanou k autorizaci nové expozice.
Prověřujte změny schématu jako změny chování
Migrace schématu může změnit více než parsování. Nová přesnost, význam směru nebo stavová pole mohou změnit sestavení objednávek, kontroly limitů a ověřování a slaďování. Považujte migraci za prověření ekonomického chování místo mechanického přejmenovávání.
Používejte uchované příklady k ověření, že nový klient dekóduje stejnou zamýšlenou expozici a stejné množství či částku. Zahrnujte zlomková množství, ceny s přesností jemnější než jeden cent, částečná plnění a rozhodnutí na straně Ne, jsou-li podporována. Potvrďte, že neznámé hodnoty vytvářejí kontrolovanou výjimku místo tichého návratu ke starému předpokladu.
Starší průvodce API bota Kalshi rozvíjí myšlenku testovatelného adaptéru. Tato hranice je užitečná i zde: zbytek aplikace by měl přijímat normalizované, dobře definované záznamy, zatímco adaptér zůstává odpovědný za překlad současných polí obchodního místa bez ztráty jejich původu nebo přesnosti.
Ověřujte obchodování přes API Kalshi jako pracovní postup účtu
Úplné prověření sleduje jeden pokyn od výběru kontraktu po konečný záznam účtu. Ověřuje jednotky, směr, ověřování identity, omezení, oprávnění, podklady o provedení a zacházení s nejistotou. Úspěšné absolvování pouze kroku sestavení požadavku ponechává většinu ekonomického pracovního postupu neprozkoumanou.
Začněte kontrolami účtu pouze pro čtení a kontrolovanými testovacími případy vhodnými pro autorizované prostředí. Procvičujte částečná plnění, odmítnuté ceny, ztracené odpovědi, opětovná připojení a změny schématu. Každý případ by měl skončit reprodukovatelnou knihou nebo výslovnou výjimkou, která brání nepodloženému pokračování.
Výsledkem je integrace, jejíž čísla si zachovávají význam na každé hranici. Přesné zpracování desetinných hodnot brání chybám jednotek, současná dokumentace brání zastaralým předpokladům a ověřování a slaďování zjišťuje, co se skutečně stalo. Společně činí z API použitelnou součást kontrolovaného procesu účtu místo pouhého způsobu odesílání ověřených požadavků.