Błędy API Polymarket: napraw każdy częsty błąd (2026, CLOB V2)

API · Rozwiązywanie problemów

Większość błędów API Polymarket ma jednozdaniową przyczynę i jednozdaniową poprawkę - ale odpowiedzi są rozproszone po zgłoszeniach na GitHubie. Ta strona zbiera błędy, na które faktycznie natrafiają deweloperzy na CLOB V2 / pUSD, wraz z przyczyną, minimalnym odtworzeniem i poprawką w Pythonie i Ruście. Wklej swój błąd poniżej, by przejść wprost do niego.

order_version_mismatch

Przyczyna. Podpisałeś zlecenie w kształcie V1 (stara domena EIP-712 Exchange w wersji "1", przestarzałe pola) i wysłałeś je na giełdę V2 (domena w wersji "2"). 28 kwietnia 2026 struktura zlecenia się zmieniła: nonce, feeRateBps, taker i expiration usunięto z podpisywanej struktury, a dodano timestamp, metadata i builder. Prawie zawsze oznacza to, że wciąż importujesz klienta V1.

Poprawka. Przejdź na SDK V2 - buduje i podpisuje strukturę V2 za ciebie.

pip install py-clob-client-v2          # V1 py-clob-client (0.34.x) is archived
from py_clob_client_v2 import ClobClient
client.create_and_post_order(order_args)   # signs the V2 struct, domain "2"

// Cargo.toml: polymarket_client_sdk_v2 = "0.5"   (official, repo rs-clob-client-v2)
use polymarket_client_sdk_v2::ClobClient;

Powiązane: invalid signature, migracja v1 → v2.

not enough balance / allowance

Przyczyna. W V2 twój portfel finansujący musi zatwierdzić kontrakty giełdy V2 do przenoszenia twojego zabezpieczenia i tokenów wyniku - a twoje zabezpieczenie musi być pUSD, nie USDC.e. Kupno wymaga zatwierdzenia (allowance) pUSD; sprzedaż wymaga zatwierdzenia CTF (ERC-1155). Brak któregokolwiek zwraca ten błąd.

Poprawka. (1) Opakuj USDC.e → pUSD, następnie (2) zatwierdź pUSD oraz tokeny warunkowe dla trzech kontraktów V2:

Użytkownicy strony są automatycznie opakowywani po jednorazowym zatwierdzeniu; traderzy korzystający tylko z API sami wywołują CollateralOnramp.wrap() (0x93070a847efEf7F70739046A929D47a521F5B8ee).

maker address not allowed, please use the deposit wallet flow

Przyczyna. Podpisujesz portfelem depozytowym POLY_1271 (typ podpisu 3). Według stanu na czerwiec 2026 klienci Python (py-clob-client-v2) i TypeScript (@polymarket/clob-client-v2) mają otwarty błąd: uwierzytelnianie L1 wiąże klucz API z twoim EOA zamiast z portfelem depozytowym, więc giełda odrzuca zlecenie.

Poprawka. Do handlu z portfela depozytowego (typ 3) użyj dziś oficjalnego klienta Rust, który poprawnie opakowuje podpis EIP-1271:

// Rust - authentication_builder().funder(deposit_wallet).signature_type(SignatureType::Poly1271)

Obejście bez Rusta: zarejestruj się przez e-mail/Magic, wyeksportuj klucz portfela Magic i użyj signature_type = POLY_PROXY (typ 1) - działa, ale nie skaluje się do wielu botów. To ruchomy błąd - sprawdzaj zgłoszenia Polymarket #70 (Python) i #65 (TS) w oczekiwaniu na poprawkę.

the order signer address has to be the address of the API KEY

Przyczyna. Portfel, który podpisał zlecenie, nie pasuje do portfela, dla którego wyprowadzono twój klucz API, albo nie przekazałeś właściwego funder/typu podpisu. Częste przy portfelach proxy i Gnosis Safe, gdy klucz podpisujący różni się od adresu przechowującego środki.

Poprawka. Wyprowadź klucz API dla tego samego portfela, którym podpisujesz, i przekaż zarówno klucz prywatny, jak i adres funder z poprawnym signature_type (1 = proxy e-mail/Magic, 2 = Gnosis Safe, 3 = portfel depozytowy).

invalid signature

Przyczyna. Zwykle jedna z: (a) podpisanie niewłaściwej domeny EIP-712 - domena Exchange V2 jest w wersji "2" (domena L1 ClobAuth pozostaje "1"); (b) dryf zegara > ~60 s między twoją maszyną a serwerem; (c) klient V1 (zobacz order_version_mismatch).

Poprawka. Użyj SDK V2, by domena/struktura były poprawne, i zsynchronizuj zegar (NTP).

401 / invalid api key / PolyApiException

Przyczyna. Brak lub błędne poświadczenia L2 (klucz/sekret/passphrase API) albo nigdy ich nie utworzyłeś. Odczyt danych rynkowych nie wymaga klucza - to dotyczy tylko wywołań uwierzytelnionych (zlecenia, twoje pozycje).

Poprawka. Utwórz lub wyprowadź poświadczenia API, a następnie przekaż wszystkie trzy w uwierzytelnionych żądaniach:

# client.create_or_derive_api_key()  -> api_key, api_secret, api_passphrase

INVALID_ORDER_MIN_TICK_SIZE

Przyczyna. Twoja cena nie jest wielokrotnością wielkości ticka rynku (często 0,01, czasem 0,001).

Poprawka. Pobierz wielkość ticka rynku (GET /tick-size) i zaokrąglij do niej cenę przed podpisaniem.

FOK_ORDER_NOT_FILLED

Przyczyna. Zlecenie Fill-Or-Kill nie mogło zostać zrealizowane w całości po twojej cenie wobec bieżącej płynności w księdze, więc zostało anulowane (to FOK działający zgodnie z założeniem, a nie awaria).

Poprawka. Najpierw odczytaj księgę i dobierz wielkość do dostępnej głębokości, poszerz cenę lub użyj GTC/FAK zamiast FOK.

invalid amounts (miejsca dziesiętne)

Przyczyna. Kwoty muszą respektować precyzję dziesiętną - kwota makera do 2 miejsc, kwota takera do 4 miejsc. Nadmiarowa precyzja jest odrzucana.

Poprawka. Zaokrąglaj/kwantyzuj przed podpisaniem; pozwól SDK V2 obliczyć kwoty z ceny × wielkość.

Size lower than the minimum: 5

Przyczyna. Zlecenia poniżej minimalnej wielkości udziałów (5) są odrzucane.

Poprawka. Zwiększ wielkość zlecenia do ≥ 5 udziałów.

429 / dławienie

Przyczyna. Przekroczyłeś limit w oknie przesuwnym. Limity V2 są wysokie (CLOB ~9000 / 10 s; /book,/price 1500 / 10 s; Gamma 4000 / 10 s; Data 1000 / 10 s), a żądania ponad limit są dławione/kolejkowane, a nie twardo odrzucane - ale ogranicznik po stronie klienta i tak jest rozsądny.

Poprawka. Dodaj ogranicznik typu token-bucket i wykładniczy backoff przy 429.

Dalej: Uwierzytelnianie i portfele · Dokumentacja API CLOB · Szybki start z API.