שילוב OKX API באפליקציית קריפטו למובייל
לעתים קרובות אנו פוגשים צוותים שעוברים מ-Binance ל-OKX ונתקלים בהבדלים מהותיים בארכיטקטורת ה-API. OKX היא אחת הבורסות הבודדות שבהן REST ו-WebSocket חיים במרחבי URL שונים עם לוגיקת אימות שונה. REST הולך ל-https://www.okx.com/api/v5/, WebSocket ל-wss://ws.okx.com:8443/ws/v5/public ול-/private. אם מעבירים את הארכיטקטורה "כמו שהיא", מחכות הפתעות.
אנחנו מפתחי מובייל עם ניסיון של 5+ שנים, שביצענו למעלה מ-30 אינטגרציות עם בורסות קריפטו, כולל OKX, Binance ו-Bybit. לדוגמה, עבור סטארטאפ פינטק אחד, חיברנו מסחר ספוט ונתונים היסטוריים ב-OKX תוך שלושה שבועות, מה שאיפשר להם להיכנס לשוק חודשיים לפני המתחרים. המודולים שצברנו מקצרים את זמן האינטגרציה ל-2–4 שבועות לפונקציונליות בסיסית.
המאפיינים הייחודיים של OKX דורשים הבנה ברורה של סכמת החתימה, סוגי המכשירים ומצבי המסחר כדי למנוע שגיאות קריטיות בסביבת הייצור. בואו נפרק את הנקודות המרכזיות בהתבסס על תיעוד ה-API של OKX.
איך לחתום על בקשות ל-OKX REST API?
OKX מאמתת בקשות דרך כותרות HTTP, לא דרך מחרוזת השאילתה או הגוף:
-
OK-ACCESS-KEY— מפתח API -
OK-ACCESS-SIGN— Base64(HMAC-SHA256(timestamp + method + requestPath + body)) -
OK-ACCESS-TIMESTAMP— ISO 8601 עם מילישניות -
OK-ACCESS-PASSPHRASE— סוד שלישי
requestPath כולל את מחרוזת השאילתה: עבור GET /api/v5/account/balance?ccy=BTC, חתמו על /api/v5/account/balance?ccy=BTC. הגוף עבור בקשת GET הוא מחרוזת ריקה "". שגיאה {"code":"50113","msg":"Invalid Sign"} כמעט תמיד אומרת בעיה עם requestPath — 80% משגיאות כאלה נגרמות מהכללה לא נכונה של מחרוזת השאילתה. חותמת זמן בפורמט ISO 8601 עם מילישניות היא נדירה. באנדרואיד, Instant.now().toString() נותן את הפורמט הנדרש החל מ-API 26. לגרסאות ישנות יותר — SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSS'Z'", Locale.US) עם אזור זמן UTC.
| פרמטר | OKX | Binance |
|---|---|---|
| מיקום החתימה | כותרות | כותרות (X-MBX-*) |
| אלגוריתם | HMAC-SHA256 | HMAC-SHA256 |
| הכללת מחרוזת שאילתה | כן | לא |
| פורמט חותמת זמן | ISO 8601 עם מילישניות | Unix במילישניות |
| סיסמה (Passphrase) | נדרשת | לא |
למה WebSocket פרטי מורכב יותר ממה שנראה?
אימות הסשן של OKX שונה מ-REST: אתם שולחים JSON עם op: "login", שבו timestamp הוא שניות Unix (לא מילישניות, לא ISO). חתימה: HMAC-SHA256(timestamp + "GET" + "/users/self/verify").
{ "op": "login", "args": [{ "apiKey": "...", "passphrase": "...", "timestamp": "1705312200", "sign": "..." }] } ההבדל הזה הוא מקור תדיר לשגיאות בעת רפקטורינג של מודול אימות משותף. 90% מהמפתחים שוכחים להחליף את פורמט חותמת הזמן, מה שמוביל לכשל באימות. OKX מנתקת את סשן ה-WebSocket אחרי 30 שניות ללא פעילות. Ping/pong אינו סטנדרטי: שלחו את המחרוזת { "op": "login", "args": [{ "apiKey": "...", "passphrase": "...", "timestamp": "1705312200", "sign": "..." }] } , קבלו "ping". לא JSON אלא מחרוזת גולמית — ספריות שעובדות רק עם מסגרות טקסט JSON נשברות.
מה לעשות עם שגיאה 50113?
שגיאה 50113 "Invalid Sign" היא הנפוצה ביותר במהלך אינטגרציה. בדקו:
- מחרוזת השאילתה כלולה ב-requestPath
- הגוף ריק עבור GET
- חותמת זמן בפורמט ISO 8601 עם מילישניות
- הסיסמה תואמת לזו שהוגדרה בעת יצירת מפתח ה-API
ניואנסים של לוגיקת המוצר
OKX תומכת ב-"pong": instType, SPOT, MARGIN, SWAP, FUTURES. אותו טיקר קיים במספר instTypes עם חוקים שונים. בעת יישום טופס הזמנה, חייבים להעביר במפורש OPTION — אחרת הבורסה מחזירה instType. תכונה נוספת היא {"code":"51001","msg":"Instrument ID does not exist"}: tdMode עבור ספוט, cash או cross עבור מרג'ין. ממשקי מובייל לעתים קרובות מסתירים את הבחירה הזו "למען הפשטות", מה שמוביל לפתיחת פוזיציות מרג'ין בטעות. אנו ממליצים על בחירה מפורשת בממשק עם אזהרה.
| שגיאה | סיבה | פתרון |
|---|---|---|
| 50113 Invalid Sign | requestPath שגוי (מחסור במחרוזת שאילתה או לוכסן נוסף) | בדקו את היווצרות הנתיב עם מחרוזת השאילתה |
| 51001 Instrument ID does not exist | instType לא צוין | העבירו במפורש instType עבור כל מכשיר |
| ניתוק WebSocket | חותמת זמן שגויה בהתחברות | השתמשו בשניות Unix, לא ב-ISO |
| הזמנה במצב מרג'ין | בחירת tdMode מוסתרת | הציגו מתג מפורש עם אזהרה |
עבודה עם נתונים היסטוריים
OKX מגבילה נרות: isolated מחזירה מקסימום 300 רשומות. כדי לטעון היסטוריה תוך גלילה לאחור, יש צורך בבקשה מפולחת עם הפרמטר GET /api/v5/market/candles (מזהה נר). הטעות הסטנדרטית היא שימוש ב-before במקום after, מה שגורם לנתונים בסדר הפוך ואז היפוך המערך בממשק עם חפצים ויזואליים. סביבת הדמו של OKX מאפשרת לבדוק פילוח ללא סיכון כספים אמיתיים.
שגיאות אופייניות בשילוב OKX
- requestPath שגוי (שכחתם מחרוזת שאילתה או הוספתם לוכסן נוסף) - שימוש ב-ISO במקום שניות Unix בהתחברות WebSocket - חוסר טיפול ב-ping/pong לא סטנדרטי - חסר instType בעת ביצוע הזמנה - החלפת `before` ב-`after` לפילוח נרותאיך אנחנו מפשטים את האינטגרציה?
אנו מציעים מודולי חתימה מוכנים עבור Swift, Kotlin, Flutter ו-React Native. הם מכסים REST ו-WebSocket, ובוחרים אוטומטית את פורמט חותמת הזמן. כתוצאה מכך, החיסכון הממוצע בתקציב על פיתוח שכבת האימות הוא 40% — פי שניים מהר יותר מהממוצע בשוק. בדיקות בסביבת הדמו של OKX מאיצות את הדיבוג פי שלושה בהשוואה לבורסות ללא סביבת ארגז חול. אנו מבטיחים שהייצור שלכם לא יתקל בשגיאות 50113 או 51001. המהנדסים שלנו משלבים התראות push (APNs) להתראות מסחר ומגדירים deep linking למעבר מקישורי אינטרנט לתוך האפליקציה.
מה כלול
- תיעוד אינטגרציה עם דוגמאות קוד ב-Swift, Kotlin, Flutter ו-React Native
- מתאמים לחתימת REST וניהול סשן WebSocket
- הגדרת Keychain/key store עבור iOS/Android
- פיתוח ממשק לבחירת instType ו-tdMode עם אזהרות
- תמיכה לאחר פריסה למשך שבועיים
תהליך העבודה
- ניתוח הארכיטקטורה שלכם ובחירת מחסנית (Flutter/React Native/Native)
- עיצוב מודול האימות וניהול המצב
- יישום שכבת REST + WebSocket עם טיפול בשגיאות
- בדיקות בסביבת הדמו של OKX ועם מפתחות אמיתיים
- פריסה ל-App Store / Google Play עם המלצות לסקירה
לוחות זמנים משוערים
אינטגרציה בסיסית (נתוני שוק + מסחר ספוט) — בין 2 ל-4 שבועות. נגזרים ומרג'ין — הוסיפו עוד 3–4 שבועות ללוגיקת עסקית ובדיקת מקרי קצה. העלות מחושבת באופן אישי לפי מורכבות הפרויקט. צרו קשר לייעוץ מפורט והזמינו שילוב OKX API עם מודולי חתימה מוכנים — אנו מבטיחים מסחר חלק באפליקציה שלכם.