Bot handlowy API Kalshi: żądania podlegające uzgodnieniu

Określ zamiar ekonomiczny przed żądaniem

Strategia powinna wyrażać swoje cele w kategoriach zachowujących znaczenie poza treścią żądania HTTP. Zamiar wskazuje kontrakt, pożądaną zmianę kierunkową, maksymalną ilość, akceptowalną cenę i termin. Zapisuje także zatwierdzenie dopuszczające działanie i alokację konta, którą może zużyć.

Ten zapis różni się od próby żądania. Próba ma znacznik czasu, cel, podpis oraz odpowiedź lub błąd. Z jednym zamiarem może wiązać się kilka prób, lecz klient nie powinien mylić liczby prób z liczbą autoryzowanych pozycji.

Trwale zapisz zamiar przed wykonaniem działania. Jeśli klient najpierw wysyła, a potem zapisuje, awaria między tymi krokami pozostawia skutek na koncie bez lokalnego wyjaśnienia. Wcześniejszy zapis pozwala ponownie uruchomionemu procesowi wykryć nierozstrzygnięty zamiar i zbadać sprawę zamiast zakładać, że nie doszło do transakcji.

Zapis nie musi być duży. Powinien zawierać dość informacji do odtworzenia proponowanego działania ekonomicznego i odróżnienia go od innej propozycji. Kod przyczyny taki jak wejście na podstawie prognozy jest przydatny tylko wtedy, gdy wskazuje konkretną prognozę i wersję zasad autoryzujące zlecenie.

Poradnik projektowania API bota rynków predykcyjnych omawia rozdział zasad i dostępu do konta. Na tej granicy kluczowa zasada mówi, że szczegóły transportu mają realizować zatwierdzony zamiar, a nie tworzyć nowe zasady handlowe przez przypadkowe wartości domyślne.

Uwierzytelnianie bota handlowego API Kalshi

Uwierzytelnianie bota handlowego API Kalshi powinno dokładnie przestrzegać aktualnego oficjalnego schematu. Poradnik uwierzytelnionych żądań określa identyfikator klucza API, znacznik czasu w milisekundach oraz podpis RSA-PSS w base64 z użyciem SHA256. Podpisywana wiadomość łączy znacznik czasu, metodę HTTP i pełną ścieżkę żądania bez parametrów zapytania.

Większość błędów implementacji w tym miejscu dotyczy reprezentacji. Znacznik w sekundach nie jest znacznikiem w milisekundach. Ścieżka powtórzona dlatego, że dwie funkcje pomocnicze dodają przedrostek, nie jest zamierzoną ścieżką. Podpisanie innej metody niż wysyłana tworzy żądanie, którego dowód autoryzacji nie opisuje rzeczywistego działania przesyłanego siecią.

Buduj cel i ścieżkę podpisu z tej samej zweryfikowanej definicji żądania. Zmniejsza to ryzyko, że jedna funkcja podpisze ścieżkę, a druga wyśle do innej lokalizacji. Testy powinny obejmować ścieżkę z parametrami zapytania i bez nich.

Oddzielaj podpisywanie od zwykłych danych diagnostycznych. Dzienniki mogą zachowywać metodę, bezpieczny opis ścieżki, identyfikator zamiaru i klasyfikację odpowiedzi bez zapisywania klucza prywatnego. Eksport dla pomocy technicznej nie powinien ujawniać materiału autoryzującego przyszłe działania na koncie.

Traktuj błąd uwierzytelnienia jako powód do sprawdzenia danych uwierzytelniających, obsługi zegara i konstrukcji żądania. Szybkie powtarzanie tego samego nieprawidłowego żądania go nie naprawia. Strategia powinna nadal nie mieć możliwości tworzenia nowej ekspozycji, dopóki klient nie potwierdzi prawidłowości uwierzytelnionego obrazu konta.

Używaj aktualnego słownictwa zleceń zdarzeniowych

Aktualna dokumentacja tworzenia zlecenia V2 wykorzystuje ścieżkę zleceń zdarzeniowych, stronę arkusza bid lub ask, liczbę kontraktów jako ciąg znaków i stałoprzecinkową cenę w dolarach. Cena jest wyrażona na skali YES: bid kupuje YES, a ask sprzedaje YES. Nie należy kopiować starszej treści żądania do nowego klienta bez sprawdzenia bieżącego kontraktu API.

Przekładaj język strategii na tę reprezentację w jednym miejscu. Strategia może mówić o uzyskaniu ekspozycji NO, podczas gdy żądanie używa ceny na skali YES. Ten przekład powinien być jawny i przetestowany, aby późniejsza zmiana wyświetlania nie odwróciła po cichu zlecenia.

Sprawdź konwersję na hipotetycznym przykładzie. Jeśli zamierzony limit ekonomiczny to zapłata najwyżej 32 centów za NO w prostym kontrakcie binarnym, dopełniająca cena na skali YES wynosi 68 centów. Adapter musi zachować jednocześnie zamierzony kierunek i limit. Zmiana samej strony przy pozostawieniu niepowiązanej konwencji ceny może skutkować inną transakcją.

Oddzielaj modele żądań i odpowiedzi. Zwięzła odpowiedź na utworzenie może potwierdzić zlecenie bez wszystkich pól używanych w pełnym obrazie zlecenia na koncie. Klient nie powinien uzupełniać brakujących pól optymistycznymi założeniami, takimi jak pełna realizacja lub brak pozostałej ekspozycji.

Niezgodność schematu powinna widocznie zatrzymać tę ścieżkę działania. Jeśli wymagane pole jest nieobecne lub ma nieznane znaczenie, cicha akceptacja może uszkodzić późniejsze rozliczenia. Wąska awaria jest lepsza niż ogólnie udane żądanie o nieznanej interpretacji ekonomicznej.

Obsługuj stałoprzecinkowe ceny bota handlowego API Kalshi

Stałoprzecinkowe ceny bota handlowego API Kalshi powinny zachowywać dokładność podczas walidacji, obliczeń i serializacji. Oficjalny poradnik reprezentacji stałoprzecinkowej opisuje dolarowe ciągi znaków, ułamkowe liczby kontraktów i zakresy cen właściwe dla rynku. Uniwersalne założenie, że każda prawidłowa cena jest całym centem, już nie wystarcza.

Używaj arytmetyki dziesiętnej lub starannie określonej reprezentacji ze skalowanymi liczbami całkowitymi. Ważne jest zachowanie zamierzonej wartości prawidłowego wejścia, takiego jak 0,1250. Zaokrąglenia binarnych liczb zmiennoprzecinkowych nie powinny decydować, czy proponowana cena znajduje się na akceptowanej przez rynek siatce.

W przykładowym obliczeniu 12,50 kontraktu po 0,2400 dolara daje kwotę zakupu dokładnie 3 dolary przed opłatami. Parser pomijający ułamkowe pół kontraktu zapisze zamiast tego 2,88 dolara, pozostawiając różnicę 12 centów. Parser mylący dolary z centami tworzy znacznie większy błąd.

Przed wysłaniem weryfikuj ceny względem aktualnej siatki rynku. Jeśli model teoretyczny sugeruje 0,237 dolara, ale właściwy przedział dopuszcza inny krok, klient potrzebuje określonej polityki zaokrąglania. Zaokrąglenie w stronę bardziej agresywnej ceny może naruszać maksymalny koszt strategii, więc polityka musi respektować limit ekonomiczny.

Zachowuj pierwotne wejście i znormalizowaną wartość w dowodach diagnostycznych. Pozwala to osobie sprawdzającej odróżnić błąd źródła od błędu konwersji. Ułatwia też testowanie późniejszych zmian reprezentacji, ponieważ te same zapisane przypadki można przepuścić przez stare i nowe adaptery.

Oddzielaj liczbę kontraktów, cenę i gotówkę

Na ekranie zlecenia często blisko siebie występują trzy wielkości: kontrakty, dolary za kontrakt i całkowita gotówka. Nie są zamienne. Pole nazwane kwotą jest zbyt niejasne dla modelu wewnętrznego, chyba że jego jednostka jest stała i jasno udokumentowana.

Używaj nazw i typów niosących znaczenie. Ilość kontraktów może być ułamkowa. Cena limitu opisuje kwotę na kontrakt. Szacowane obciążenie obejmuje iloczyn ilości i ceny oraz rezerwę na odpowiednie koszty. Rzeczywisty przepływ gotówki wynika z zapisanego wyniku na koncie, który może różnić się od szacunku.

Hipotetyczny zamiar zakupu 25 kontraktów po 44 centy ma kwotę zakupu 11 dolarów. Nie jest instrukcją wydania 25 dolarów ani zleceniem na 44 dolary. Te rozróżnienia mogą wydawać się oczywiste, lecz łatwo je zgubić, gdy kilka punktów końcowych używa różnych nazw pól lub jednostek.

Wbuduj kontrole jednostek w granicę żądania. Cena poza dozwolonym zakresem kontraktu, ujemna ilość zakupu lub szacunek gotówki niemożliwy do uzgodnienia z wielkością i ceną powinny być odrzucone przed podpisaniem. Takie kontrole są przydatniejsze niż odkrycie błędu po odrzuceniu żądania przez platformę.

Przegląd API handlu na rynkach predykcyjnych umieszcza te reprezentacje w szerszym kontekście integracji. Dobry klient zachowuje jawne jednostki na całej drodze od obserwacji źródłowej do raportu konta, zamiast liczyć na to, że interfejs użytkownika wywnioskuje je na końcu.

Zachowaj jeden identyfikator przy niepewnych próbach

Utwórz lokalny identyfikator zamiaru i odpowiedni identyfikator zlecenia klienta przed wysłaniem. Zapisz powiązanie z identyfikatorem zlecenia serwera, gdy stanie się znany. Tożsamości te pozwalają połączyć późniejszy zapis konta z działaniem, które go spowodowało.

Oficjalny przewodnik szybkiego startu opisuje wykrywanie duplikatów przy użyciu identyfikatora zlecenia klienta. Funkcja ta jest przydatna, lecz klient nadal powinien prowadzić własny dziennik zamiarów i sprawdzać bieżące dowody konta. Nie zamieniaj udokumentowanej kontroli duplikatów w niepoparte twierdzenie, że dowolne żądanie można bez końca odtwarzać w każdych warunkach.

Jeśli po transmisji zlecenie przekroczy czas odpowiedzi, wynik jest nieznany. Klient powinien zachować pierwotny zamiar ekonomiczny i zarezerwowaną dla niego kwotę. Może następnie sprawdzić zlecenia i realizacje lub wykonać udokumentowane ponowienie zachowujące właściwą tożsamość. Domyślne tworzenie świeżego identyfikatora w reakcji na niepewność grozi drugim niezależnym zobowiązaniem.

Odpowiedź o duplikacie sama może stanowić przydatny dowód. Może wskazywać, że pierwotne działanie dotarło do platformy, lecz sama nie dowodzi wielkości realizacji. Prześledź tożsamość do zapisu konta i wyjaśnij pozostałą ekspozycję.

Zachowuj dziennik między restartami. Identyfikator zapisany tylko w pamięci procesu znika właśnie wtedy, gdy odtwarzanie może najbardziej go potrzebować. Trwałość nie jest tu abstrakcyjną preferencją bazy danych; zachowuje związek zatwierdzonej decyzji ze skutkami na koncie, które mogą już istnieć.

Klasyfikuj przypadki polityki ponawiania bota handlowego API Kalshi

Polityka ponawiania bota handlowego API Kalshi powinna odróżniać nieprawidłowe wejście, odmowę uprawnień, presję limitów, awarię transportu i niepewny wynik ekonomiczny. Kategorie te nie wymagają tej samej reakcji. Jedna ogólna pętla ponowień może zamienić mały problem połączenia w większy problem konta.

Nieprawidłowa siatka cenowa lub błędnie zapisana ilość wymagają poprawki. Odmowa dostępu wymaga zrozumienia uprawnienia lub statusu konta. Presja limitów wymaga regulacji tempa i priorytetów. Utracona odpowiedź po zapisie wymaga uzgodnienia. Tymczasowy błąd odczytu może pozwolić na kolejną próbę obserwacji bez autoryzowania nowej pozycji.

Każde ponowienie powinno nadal respektować termin zamiaru. Wejście oparte na cenie, sensowne przed publikacją, może już nie mieć zastosowania po kilku sekundach opóźnienia. Skuteczne dostarczenie wygasłej transakcji nie jest skuteczną realizacją pierwotnych zasad.

Dla powtarzalnej komunikacji stosuj ograniczone wydłużanie przerw, z limitem liczby prób i upływu czasu. Limity należy dobrać do wartości i pilności zadania. Wyczerpanie polityki ponowień powinno tworzyć jasny stan nierozstrzygnięty, a nie niewidoczną pętlę działającą bez końca.

Zapisuj powód każdej próby. Późniejsza osoba sprawdzająca powinna móc zobaczyć, czy klient pozyskiwał świeże dowody, ponawiał udokumentowane działanie bezpieczne wobec duplikatów czy badał niepewność. Rozróżnienie pomaga ustalić, czy rzeczywisty problem dotyczy odpowiedzi platformy, lokalnej konstrukcji żądania czy założeń czasowych strategii.

Zachowuj dostępny limit odczytu na odtwarzanie stanu

Klient może utracić użyteczną kontrolę, jeśli rutynowe odpytywanie zużyje limit potrzebny do sprawdzenia niepewnego zlecenia. Planowanie limitów powinno więc rezerwować miejsce na odtwarzanie konta i redukcję ryzyka, zamiast traktować każde żądanie jako równie wartościowe.

Bieżące limity Kalshi używają kosztów tokenowych i budżetów właściwych dla konta. Dokumentacja limitów rozróżnia zasoby odczytu i zapisu oraz opisuje aktualne szczegóły kierowania żądań. Klient powinien pozyskiwać odpowiednią konfigurację, zamiast zakładać jedną stałą liczbę żądań na sekundę dla każdego konta i punktu końcowego.

Rozważ hipotetyczny harmonogram o ograniczonym limicie odczytu. Pełne skanowanie setek niepowiązanych rynków może mieć niższy priorytet niż sprawdzenie realizacji niedawnego zlecenia. Jeśli skan blokuje tę kontrolę, strategia może dłużej pozostawać w niepewności i albo przegapić uzasadnione działania, albo podjąć niebezpieczne.

Przetwarzanie partiami i strumienie mogą zmniejszyć część pracy, lecz nie eliminują potrzeby rozumienia znaczenia punktów końcowych. Partia może zawierać mieszane wyniki. Strumień może się rozłączyć. Harmonogram powinien priorytetowo traktować informacje wymagane do ustalenia bieżących zobowiązań konta.

Mierz koszt żądań według przeznaczenia. Oddzielaj wykrywanie rynków, zwykłą obserwację, dalszą obsługę zleceń i odtwarzanie. Pozwala to ograniczać pracę w tle przy wzroście presji bez przypadkowego wyłączania kontroli chroniących konto.

Odtwarzaj częściowe realizacje bez podwójnego liczenia

Częściowa realizacja zmienia zarówno stan posiadania, jak i pozostałą ekspozycję zlecenia. Klient musi zachowywać oba fakty. Żądana ilość 30 z 12 zrealizowanymi i 18 nadal aktywnymi różni się od zamkniętego zlecenia, które zrealizowało tylko 12.

Wiedz, czy każde pole jest skumulowane czy przyrostowe. Jeśli odpowiedź pokazuje całkowitą zrealizowaną ilość 12, a późniejsza 20, dodatkowa realizacja wynosi osiem. Dodanie obu sum tworzy fałszywą pozycję 32. Przyrostowe zdarzenia realizacji wymagają innego traktowania, w tym wykrywania duplikatów.

Anulowanie może ścigać się z realizacją. Ostateczny zapis musi dopuszczać wykonanie części ilości przed usunięciem pozostałego zlecenia. Sukces anulowania nie cofa wcześniejszych realizacji ani nie dowodzi, że pierwotne żądanie nie wywarło skutku.

Używaj pozycji konta jako kontroli krzyżowej, pamiętając, że migawki mogą przedstawiać różne czasy obserwacji. Celem jest wyjaśnione uzgodnienie, a nie wymuszanie identyczności wszystkich odpowiedzi punktów końcowych w każdej chwili. Zachowuj znaczniki czasu i sekwencję dowodów użytych do wyjaśnienia różnicy.

Poradnik synchronizacji konta rynków predykcyjnych rozwija to rozumowanie na poziomie systemu. Na granicy API zasadniczym zadaniem jest zachowanie wystarczających szczegółów tożsamości i ilości, aby późniejsze uzgodnienie można było wykonać dokładnie.

Testuj granicę celowo wprowadzanymi usterkami

Przydatne testy klienta skupiają się na błędach mogących zmienić znaczenie ekonomiczne. Testuj ilość ułamkową, cenę na granicy przedziału, wygasły zamiar i nieznane pole odpowiedzi. Każdy przypadek powinien mieć oczekiwaną decyzję możliwą do sprawdzenia bez rzeczywistej transakcji.

Następnie testuj niepewność komunikacji. Zasymuluj zniknięcie odpowiedzi po przyjętym żądaniu. Uruchom klienta ponownie, gdy zamiar pozostaje nierozstrzygnięty. Oczekiwane zachowanie to odzyskanie istniejącego zamiaru i sprawdzenie wyniku na koncie, a nie rozpoczęcie świeżej decyzji strategii od pustego stanu.

Testuj także błędne dane źródłowe. Brakująca cena nie powinna stawać się zerem. Ciąg znaków niemożliwy do odczytania nie powinien stawać się domyślną ilością. Odrzucenie bezużytecznych danych z wyjaśnieniem jest pomyślnym wynikiem testu.

Utrzymuj dane uwierzytelniające i rzeczywiste działania konta poza zwykłymi automatycznymi testami. Kontrolowany zestaw danych może ustalić zachowanie konwersji i klasyfikacji. Oddzielne autoryzowane ćwiczenie demonstracyjne może potem sprawdzić łączność bez traktowania fikcyjnej płynności jako dowodu jakości rzeczywistej realizacji.

Na koniec zachowuj przypadki usterek w miarę ewolucji API. Wartość zestawu regresyjnego polega na zachowaniu oczekiwań ekonomicznych przy zmianie kształtu żądania. Aktualizacja jest akceptowalna, gdy nadal daje zamierzone ograniczone zachowanie, a nie tylko gdy się kompiluje lub zwraca udany status HTTP.

Traktuj zmiany API jako wymagający przeglądu przekład

Zmiana API powinna wyzwalać przegląd założeń adaptera. Nowe nazwy pól mogą być proste, lecz zmieniona konwencja cenowa, znaczenie ilości lub kompletność odpowiedzi mogą zmienić zachowanie konta, nawet gdy kod nadal działa.

Prowadź niewielki zapis zgodności wymieniający przejrzaną dokumentację, obsługiwane kształty żądań i przypadki testowe ustalające ich znaczenie. Unikaj opisywania klienta jako trwale zgodnego. Zgodność jest dowodem powiązanym z wersją i przetestowanym zbiorem operacji.

Podczas migracji porównuj znormalizowane wyniki zapisanych przykładów. Ten sam zamiar ekonomiczny powinien dawać równoważne limity i kierunek w nowej reprezentacji. Ta sama historia realizacji powinna dawać tę samą pozycję i wyjaśnienie gotówki. Różnice należy zrozumieć przed włączeniem nowych działań.

Wąski adapter pozwala utrzymać tę pracę w rozsądnych granicach. Badania strategii mogą nadal operować jawnymi kontraktami, prawdopodobieństwami i limitami ekonomicznymi, podczas gdy jedna sprawdzona granica obsługuje bieżące konwencje platformy. Rozdział zamienia utrzymanie API w konkretny problem przekładu i daje właścicielowi jaśniejszą podstawę decyzji, kiedy klient jest ponownie gotowy do działania.

Powiązane poradniki i przykłady obliczeniowe

• Automatyczny handel przez API Kalshi: prześledź każdą decyzję — Zbuduj klienta ze śladem audytowym od wykrywania rynków po uzgadnianie konta.
• API handlowe Kalshi: wybierz właściwą warstwę danych — Wybieraj interfejsy rynku i konta, uwzględniając budżety limitów i konwencje danych.