API · פתרון תקלות

לרוב שגיאות ה-API של פולימרקט יש סיבה בשורה אחת ותיקון בשורה אחת - אך התשובות מפוזרות על פני issues ב-GitHub. העמוד הזה אוסף את השגיאות שמפתחים באמת נתקלים בהן ב-CLOB V2 / pUSD, עם הסיבה, שחזור מינימלי, והתיקון ב-Python וב-Rust. הדביקו את השגיאה שלכם למטה כדי לקפוץ אליה ישירות.

קודם כול, הסיבה השורשית מספר 1 ב-2026: אתם עדיין על ה-SDK של V1. ה-py-clob-client הישן (הגרסה האחרונה 0.34.6) וה- @polymarket/clob-client מאורכבים / הוחלפו ומייצרים פקודות שבורסת ה-V2 דוחה. עברו ל-py-clob-client-v2 (Python), ‏@polymarket/clob-client-v2 (Node) או ללקוח ה-Rust הרשמי polymarket_client_sdk_v2. פרויקטים חדשים יכולים להשתמש ב-SDK המאוחדים בבטא (polymarket-client / @polymarket/client).

order_version_mismatch

סיבה. חתמתם על פקודה בצורת V1 (דומיין Exchange ישן של EIP-712 גרסה "1", שדות מדור קודם) ופרסמתם אותה לבורסת V2 (דומיין גרסה "2"). ב-28 באפריל 2026 מבנה הפקודה השתנה: nonce, feeRateBps, taker ו-expiration הוסרו מהמבנה החתום ו-timestamp, metadata ו-builder נוספו. כמעט תמיד זה אומר שאתם עדיין מייבאים את לקוח ה-V1.

תיקון. עברו ל-SDK של V2 - הוא בונה וחותם עבורכם את מבנה ה-V2.

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;

קשור: invalid signature, מעבר v1 → v2.

not enough balance / allowance

סיבה. תחת V2 ארנק המימון שלכם חייב לאשר את חוזי בורסת ה-V2 להזיז את הבטוחה ואת טוקני התוצאה שלכם - והבטוחה שלכם חייבת להיות pUSD, לא USDC.e. קנייה צריכה הרשאת pUSD; מכירה צריכה אישור CTF (ERC-1155). היעדר אחד מהם מחזיר את השגיאה הזו.

תיקון. (1) עטפו USDC.e ← pUSD, ואז (2) אשרו את ה-pUSD ואת הטוקנים המותנים לשלושת חוזי ה-V2:

אשרו לכל שלושת חוזי ה-V2
  • CTF Exchange (V2) - 0xE111180000d2663C0091e4f400237545B87B996B
  • Neg Risk CTF Exchange - 0xe2222d279d744050d28e00520010520000310F59
  • Neg Risk Adapter - 0xd91E80cF2E7be2e162c6513ceD06f1dD0dA35296
טוקן pUSD: 0xC011a7E12a19f7B1f670d46F03B03f3342E82DFB · Conditional Tokens (CTF): 0x4D97DCd97eC945f40cF65F87097ACe5EA0476045

משתמשי האתר מקבלים עטיפה אוטומטית לאחר אישור חד-פעמי; סוחרי API-בלבד קוראים בעצמם ל- CollateralOnramp.wrap() (0x93070a847efEf7F70739046A929D47a521F5B8ee).

maker address not allowed, please use the deposit wallet flow

סיבה. אתם חותמים עם ארנק הפקדה POLY_1271 (סוג חתימה 3). נכון ליוני 2026 ללקוחות ה-Python (py-clob-client-v2) וה-TypeScript (@polymarket/clob-client-v2) יש באג פתוח: אימות ה-L1 כובל את מפתח ה-API ל-EOA שלכם במקום לארנק ההפקדה, ולכן הבורסה דוחה את הפקודה.

תיקון. למסחר מארנק הפקדה (סוג 3) כיום, השתמשו בלקוח ה-Rust הרשמי, שעוטף נכון את חתימת ה-EIP-1271:

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

פתרון עוקף ללא Rust: הירשמו דרך אימייל/Magic, ייצאו את מפתח ארנק ה-Magic והשתמשו ב- signature_type = POLY_PROXY (סוג 1) - זה עובד אך אינו מתאים להרבה בוטים. זהו באג נזיל - בדקו מחדש את issues ‏#70 (Python) ו-‏#65 (TS) של פולימרקט לתיקון.

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

סיבה. הארנק שחתם על הפקודה אינו תואם לארנק שעבורו נגזר מפתח ה-API שלכם, או שלא העברתם את ה-funder/סוג החתימה הנכונים. נפוץ עם ארנקי פרוקסי ו-Gnosis-Safe כשהמפתח החותם שונה מהכתובת שמחזיקה את הכספים.

תיקון. גזרו את מפתח ה-API עבור אותו ארנק שאתם חותמים איתו, והעבירו גם את המפתח הפרטי וגם את כתובת ה-funder עם ה-signature_type הנכון (1 = פרוקסי אימייל/Magic, 2 = Gnosis Safe, 3 = ארנק הפקדה).

invalid signature

סיבה. בדרך כלל אחד מאלה: (א) חתימה על דומיין EIP-712 שגוי - גרסת דומיין ה-Exchange של V2 היא "2" (דומיין ה-ClobAuth של L1 נשאר "1"); (ב) סטיית שעון של יותר מ-60 שניות בערך בין המחשב שלכם לשרת; (ג) לקוח V1 (ראו order_version_mismatch).

תיקון. השתמשו ב-SDK של V2 כדי שהדומיין/המבנה יהיו נכונים, וסנכרנו את השעון (NTP).

401 / invalid api key / PolyApiException

סיבה. פרטי הזדהות L2 חסרים או שגויים (מפתח/סוד/passphrase של API), או שמעולם לא יצרתם אותם. קריאת נתוני שוק אינה צריכה מפתח - זה משפיע רק על קריאות מאומתות (פקודות, הפוזיציות שלכם).

תיקון. צרו או גזרו את פרטי ההזדהות של ה-API, ואז העבירו את שלושתם בבקשות מאומתות:

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

INVALID_ORDER_MIN_TICK_SIZE

סיבה. המחיר שלכם אינו כפולה של גודל הטיק של השוק (לרוב 0.01, לפעמים 0.001).

תיקון. משכו את גודל הטיק של השוק (GET /tick-size) ועגלו אליו את המחיר שלכם לפני החתימה.

FOK_ORDER_NOT_FILLED

סיבה. פקודת Fill-Or-Kill לא הצליחה להתמלא במלואה במחיר שלכם מול הנזילות הממתינה הנוכחית, ולכן היא בוטלה (זה FOK עובד כמתוכנן, לא כשל).

תיקון. קראו קודם את ספר הפקודות והתאימו את הגודל לעומק הזמין, הרחיבו את המחיר, או השתמשו ב-GTC/FAK במקום FOK.

invalid amounts (decimals)

סיבה. הסכומים חייבים לכבד דיוק עשרוני - סכום עושה השוק ל-2 ספרות, סכום הלוקח ל-4 ספרות. דיוק עודף נדחה.

תיקון. עגלו/כמתו לפני החתימה; תנו ל-SDK של V2 לחשב סכומים ממחיר × גודל.

Size lower than the minimum: 5

סיבה. פקודות מתחת לגודל המניה המינימלי (5) נדחות.

תיקון. הגדילו את גודל הפקודה ל-‏≥ 5 מניות.

429 / throttled

סיבה. חרגתם ממגבלת קצב של חלון נע. מגבלות V2 גבוהות (CLOB כ-9,000 / 10 שניות; /book,/price 1,500 / 10 שניות; Gamma 4,000 / 10 שניות; Data 1,000 / 10 שניות) ובקשות מעבר למגבלה נחנקות/נכנסות לתור, לא נדחות באופן קשיח - אך מגביל בצד הלקוח עדיין נבון.

תיקון. הוסיפו מגביל token-bucket ו-backoff מעריכי על 429.

עדיין תקועים? ודאו שאתם על ה-SDK של V2, שהבטוחה שלכם היא pUSD, ושכל שלושת חוזי ה-V2 מאושרים. אז בדקו את אימות וארנקים ואת מעבר ה-v1 → v2.

הבא: אימות וארנקים · עיון ב-CLOB API · התחלה מהירה של API.