בוט מסחר ב-OKX: אינטגרציית API מקצה לקצה

למה אינטגרציית OKX API נשברת אחרי ההפעלה

אינטגרציית OKX API נדירה להישבר בבקשה הראשונה — בדרך כלל היא מפסיקה לעבוד ביום השלישי למסחר חי. כל עוד הנפחים קטנים, הכול נראה עובד: הזמנות יוצאות, עסקאות מבוצעות, היומן נכתב. אחר כך זרם המחירים נקטע לדקה, והבוט ממשיך להתייחס למחיר האחרון כעדכני ומגיש לפיו הזמנות.

קטיעת זרם המחירים מסוכנת בכך שהיא לא תמיד נראית לעין. החיבור פורמלית חי, חלק מההודעות אבד, והמצב המקומי מתפצל מזה של הבורסה.

בהמשך נכנס חוסר סנכרון בהזמנות: ביצוע חלקי, ביטול בגלל פסק זמן, שליחה חוזרת לאחר השהיית רשת — והיומן המקומי מצהיר ש"הפוזיציה סגורה", בעוד בבורסה היא תלויה פתוחה. לפי היומן, לעיתים קרובות כבר אי אפשר לשחזר רגע כזה.

בשיאי תנודתיות נוספים לכך כשלים מצד הבורסה והגבלות על קצב הבקשות. התשובה לא נשמרה, המצב לא הותאם — והבוט מאבד שליטה על פוזיציות פתוחות, תוך שהוא ממשיך לסחור נגד הבעלים. את זה צריך לפרק ידנית, הזמנה אחר הזמנה, ברגע הכי לא מתאים.

המחיר של תקלה — לא שעות פיתוח, אלא פוזיציות שלא נסגרו ואובדן אמון באוטומציה. אנו מפרקים כיצד זה נסגר: התאמת מצב מול הבורסה, ניסיונות חוזרים ובטוחים מפני כפילות, בקרת חיות של זרם המחירים ותרחיש שחזור ברור לאחר כשל.

האפקט של בוט מנוהל: זמן תגובה ומחלקות כשל

האפקט הראשון — זמן תגובה לתקלה. הפלטפורמה OKX מספקת זרם נתוני שוק וסטטוסים של עסקאות באופן אסינכרוני: אישור על הזמנה יכול להגיע מאוחר יותר מעדכון המחיר, וחלק מהתשובות הולכות לאיבוד בעת קטיעת הקשר.

האוטומציה מתאימה את היומן המקומי למצב החשבון ומעבירה את האסטרטגיה למצב בטוח בתוך שניות — ידנית זה לוקח דקות, וכל אותו זמן הבוט פועל בעיוורון. אנו מודדים השהיה בנפרד לפי חציון ולפי האחוזון ה-95, כדי לראות מקרים נדירים וארוכים, ולא רק את המקרה הממוצע.

התוצאה השנייה — שיעור ההזמנות שבוצעו בלי התערבות ידנית. הפקודות עוברות דרך תור עם ניסיונות חוזרים ובדיקת סטטוס, ולכן בקשה חוזרת לא יוצרת הזמנה שנייה. גישה ידנית נשארת, אך כחריג: אישור נפחים גדולים, עצירת חירום, ניתוח תקלה. מהיומן רואים כמה פעולות באמת דרשו אדם — בדרך כלל מדובר באחוזים בודדים.

התוצאה השלישית — מחלקת כשלים שנעלמה. בעבר צצו באופן קבוע כפילויות בעת חיבור מחדש, מרוצי תנאים בביצוע חלקי ופוזיציות תקועות כשהתשובה מהפלטפורמה כלל לא הגיעה.

מפתחות של בקשות חוזרות, התאמת מצבים לאחר ניתוק והגבלות על קצב הפנייה מוציאים את התרחישים האלה מהתפעול: נשארים סיכונים שוקיים, לא טכניים. עמידות הבוט בפני תקלות מפסיקה להיות תלויה במי ששומר על המסך.

השוואה של מצבי חיבור לבורסה דרך API

אינטגרציית OKX API נבנית לפי אחת מארבע תוכניות — הן נבדלות בכך היכן נמצאת לוגיקת ההזמנות, למי מועברים המפתחות ואיזו גישה לחשבון נפתחת. לא בוחרים את התוכנית "המהירה ביותר", אלא את זו שהמגבלות שלה תואמות את דרישות האבטחה ואת עומק ההטמעה של הבוט במערכות שלכם.

מה נשאר ללא שינוי

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

שלבי הטמעה: מביקורת אסטרטגיה ועד מסירת הבוט

ביקורת אסטרטגיה חוסכת יותר זמן מכל שלב פיתוח: לפני שורת הקוד הראשונה אנו מתעדים אילו הזמנות הבוט מגיש, מה נחשב לאירוע כניסה ויציאה, וכיצד המערכת מתנהגת בביצוע חלקי ובקטיעת קשר עם הבורסה.

העבודה מתנהלת בשבעה שלבים, וכל אחד מסתיים בארטיפקט שניתן לבדוק — ולכן קבלת הבוט לא הופכת לוויכוח על "איך זה היה אמור לעבוד".

1. ניתוח אסטרטגיה ותרחישי מסחר. אנו מכנסים את כללי הכניסה, היציאה וניהול הפוזיציה לתנאים חד-משמעיים; נקודות שנויות במחלוקת כמו אות בו-זמני בשני מכשירים מבהירים מיד.
2. תרשים חיבור. אנו קובעים היכן נמצא הבוט, כיצד נשמרים המפתחות, מה קורה כשאין גישה לבורסה: תור ניסיונות חוזרים, השהיה במסחר או סגירת פוזיציות בחירום.
3. הגדרת הרשאות מפתח. אנו מנפיקים מפתח לקריאה ולמסחר בלבד, בלי זכות למשיכת כספים, עם הצמדה לכתובת השרת. אנו מהדקים את ההרשאות למינימום שבו הלוגיקה עדיין עובדת.
4. הרכבת לוגיקת הביצוע. אנו מיישמים הגשה וביטול של הזמנות, טיפול בביצועים חלקיים, חשבונאות עמלות והתאמת פוזיציות בפועל מול מחושבות.
5. בדיקה במתחם בדיקות. אנו מריצים תרחישים על נתונים היסטוריים ועל סביבת הבדיקות של הבורסה: חוסר יתרה, הזמנה נדחית, ניתוק חיבור, הפעלה מחדש.
6. הפעלה בנפח קטן. אנו מוציאים את הבוט לעבודה עם גודל פוזיציה מוגבל וצופים בהתנהגות בשוק חי, תוך התאמת היומן להיסטוריית העסקאות.
7. מסירה וקבלה של הבוט. אנו מוסרים קוד מקור, תצורה, הוראות הפעלה ושחזור, ומנתחים יומנים יחד עם הצוות שלכם. הקבלה מתבצעת לפי תרחישים שסוכמו מראש, ולא לפי תחושות.

ערכת מסירה: תצורות, תרשימי אינטגרציה, נהלים

מסירה היא לא ארכיון עם קוד מקור, אלא העברת שליטה. הערכה נאספת כך שהצוות שלכם יסגור את משימות התפעול השגרתיות: לפרוס מתחם, לשנות פרמטרים של אסטרטגיה, להעניק או לשלול גישה, לשחזר עבודה לאחר תקלה.

• תרשים אינטגרציה: זרמי הזמנות, מינויים לנתוני שוק, טיפול בכשלים של OKX וניסיונות חוזרים — עם סימון מקומות שבהם מצב הבוט עלול להתפצל מיתרת החשבון.
• תצורות סביבות: מתחם עבודה ומתחם בדיקות, פרמטרים של אסטרטגיה, מגבלות נפח ומנגנוני הגנה מופרדים לקבצים נפרדים בלי שינוי בקוד.
• מדיניות גישה למפתחות: תפקידים, הפרדת הרשאות לקריאה, מסחר ומשיכת כספים, נוהל רוטציה וסדר שלילה בחירום.
• תיעוד הבוט: ייעוד כל מודול, כיצד להוסיף מכשיר או לשנות לוגיקה, אילו מדדים מאותתים ראשונים על בעיה.
• נוהל תורנות: רמות התראות, תחומי אחריות, סדר עצירת הבוט וסגירה ידנית של פוזיציות.
• תרחישי שחזור: הוראות שלב-אחר-שלב לתקלות אופייניות — הזמנה נדחית, ניתוק חיבור, אי-התאמת יתרה.
• יומן שינויים וצ'ק-ליסט קבלה: היסטוריית תיקונים עם סיבות ובדיקות חובה לפני העלאת גרסה חדשה.

חודש אחרי ההפעלה אתם לא תלויים בנו בשגרה: הצוות בעצמו משנה פרמטרים ומטפל בתקלות, ואנחנו מצטרפים לפיתוח — אסטרטגיות חדשות, שווקים, דיווח.

דוגמה מהפרקטיקה: איך הסרנו הזמנות כפולות בשוק

הלקוח — מסחר אלגוריתמי: כמה אסטרטגיות, קצב הזמנות גבוה. הסימפטום התברר כיקר: בעת קטיעת קשר הבוט שלח הזמנה שוב, והפלטפורמה קיבלה את שתיהן. הפוזיציה נפתחה כפול מהמתוכנן, וצריך היה לסגור אותה ידנית ובמחיר אחר.

ניתוח יומן העסקאות הראה את הסיבה. הרשומות נכתבו בדיעבד, מזרמים שונים ובלי מזהה משותף. ניתן היה להתאים עסקה להזמנה שיצרה אותה רק לפי זמן ונפח — כשהערכים תאמו, לא התקבלה מסקנה חד-משמעית. בדיקת ביצוע ההזמנות לא הייתה כלל: הצלחה נחשבה לשליחה, ולא למצב מאושר של ההזמנה בבורסה.

מה שינו. כל בקשה קיבלה מזהה לקוח קבוע, ושליחה חוזרת בוצעה רק איתו — הפלטפורמה OKX מזהה חזרה ולא יוצרת הזמנה שנייה. לפני ניסיון חוזר הבוט מבקש את המצב בפועל של הפוזיציה וההזמנות הפתוחות, ולא סומך על מונה מקומי. יומן העסקאות הפך לאחיד: כוונה, תשובת הפלטפורמה ואישור ביצוע נכתבים כרשומה אחת עם מפתח משותף.

מדדים לפני ואחרי. הזמנות כפולות: 4–6 מקרים בשבוע בהתחלה — אפס במשך רבעון תצפיות אחרי התיקונים. זמן התגובה לפער בין המצב המקומי לזה של הבורסה הצטמצם מ-20–40 דקות ל-15–20 שניות. שיעור ההזמנות שעוברות בלי התערבות ידנית עלה מ-71% ל-99.4%.

מסקנה לאינטגרציות מהסוג הזה: התאמת מצב חשובה ממהירות השליחה. לכן בדיקת ביצוע ההזמנות נכללת במתחם מהיום הראשון, ולא מתווספת אחרי התקלה הראשונה.

מה לעשות אם כבר פועל אצלכם בוט של קבלן אחר?

בוט עובד של קבלן אחר אנחנו לא כותבים מחדש מאפס — כך הולכת לאיבוד לוגיקה שכבר מניבה תוצאה. מתחילים בביקורת של הבוט הקיים: מפרקים את כללי הכניסה והיציאה, העבודה עם הזמנות, הטיפול בביצועים חלקיים ובקטיעות קשר, בודקים היכן נשמרים מפתחות OKX API ואיך מוגבלות ההרשאות שלהם. אחרי הביקורת רואים מה מועבר ללא שינוי ומה דורש עיבוד מחדש.

העברת לוגיקת המסחר מתבצעת לפי מפרט כתוב: כל כלל נרשם כתנאי עם פרמטרים, כדי שאפשר יהיה להשוות את התנהגות הגרסה החדשה לזו הקודמת, ולא לדון בכך בעל פה.

בנפרד אנו בודקים את חישוב גודל הפוזיציה, מגבלות על מספר עסקאות והתגובה לכשל של הבורסה — דווקא כאן לרוב יש פער בין הציפיות להתנהגות בפועל.

בהמשך — הרצה מקבילה: הגרסה הישנה והחדשה עובדות על מפתחות נפרדים, ואנחנו משווים אותות, זמן תגובה וביצוע בפועל. פערים מפרקים אחד-אחד: היכן טעות בהעברה והיכן המתחם הקודם התנהג שלא כשורה. ההרצה מספקת הוכחה שהלוגיקה החדשה משחזרת את ההתנהגות הרצויה, ולא חוזרת על תקלות ישנות.

החלפת קבלן מתבצעת בשלבים: העברת נפח בחלקים, הבוט הישן נשאר רזרבה עובדת עד סוף ההתאמה, והגישות והמפתחות נשארים אצלכם כל הזמן. במקביל אנו מוסרים תיעוד ללוגיקה ונוהל נסיגה — כדי שלא תהיו תלויים בצוות אחד ותוכלו לחזור למתחם הקודם בכל רגע.

תארו את המשימה הנוכחית ותנו גישה להיסטוריית העסקאות — נחזור עם הערכת היקף ההעברה ותוכנית עבודה.

מפתחות, מגבלות ואמינות: תשובות לשאלות נפוצות

כל ארבע השאלות — על מפתחות, מגבלות בקשות, קטיעות קשר וליווי — נשאלות לפני ההתחלה: התשובות עליהן קובעות את הארכיטקטורה, ולא את פרטי המימוש. להלן מה שאנו מפרקים עם הלקוח לפני שורת הקוד הראשונה.

מה קורה בעת קטיעת קשר עם הבורסה?

לקוח האינטגרציה מנהל מונה מקומי של תפוסת מגבלות הבורסה, ולכן השהיה בשליחת בקשות היא מצב רגיל, לא כשל: כשהחלון מתמלא, הבקשות נכנסות לתור ויוצאות מאוחר יותר.

כל בקשה נשלחת עם מזהה משלה — אחרי ניתוק, שליחה חוזרת לא יוצרת עסקה שנייה, והפוזיציה והיתרה מותאמות מול הבורסה לפני חידוש המסחר.

מי אחראי להחלטות המסחר?

הבוט מבצע כללים שסוכמו איתכם ונרשמו בתצורה: אנחנו אחראים לכך שהם יבוצעו במדויק ובאופן משוחזר, לחשבונאות עמלות ולנכונות חישוב נפח ההזמנה. ההחלטות על הלוגיקה עצמה נשארות בצד הלקוח.

מה כלול בתמיכה אחרי ההפעלה?

מעקב אחר החיבור ויומני העסקאות, התראות על תקלות, תגובה לשינויים מצד הבורסה — כללי המגבלות ופורמטי התשובות משתנים, ואנחנו מתאימים את ההגדרות. השלמת לוגיקת המסחר מתבצעת במשימות נפרדות.

נדון במשימה: מה לשלוח להערכה מדויקת

הערכה מדויקת של הפרויקט נשענת על נתוני מקור: ככל שהתיאור מפורט יותר, כך יש פחות הנחות בתוכנית העבודה ופחות הפתעות בקבלה. להלן מה לשלוח כדי שנחזור עם הערכה ותוכנית עבודה, ולא עם מילים כלליות.

• לוגיקת האסטרטגיה: אילו אירועים פותחים וסוגרים פוזיציה, באילו מרווחים מחושבים האותות, כיצד מטופלים ביצועים חלקיים וקטיעות קשר עם הבורסה.
• מצב נוכחי: שפה וספריות, היכן הבוט פועל, כיצד נשמרים המפתחות והתצורה, האם יש יומני עסקאות לתקופה קודמת.
• גישות: מתחם בדיקות OKX ומפתח עבודה עם הרשאות למסחר בלבד, בלי משיכת כספים; אין לשלוח סודות בהתכתבות — תארו את סכימת האחסון, והחלפת גישות תיעשה בערוץ מאובטח.
• מגבלות: מגבלות על קצב בקשות, רשימת זוגות מסחר מותרת, גודל פוזיציה מקסימלי, דרישות ליומן פעולות.
• מה כבר נעשה: תוצרים, קונפיגים, טבלאות שהאינטגרציה צריכה להתחבר אליהם, ומה שאפשר לזרוק בלי לאבד דבר.
• קריטריוני מוכנות: אילו תרחישים צריכים לעבוד במתחם הבדיקות ומי מצד הלקוח מקבל את התוצאה.
• לוחות זמנים ותקשורת: תאריך הפעלה קשיח, חלונות לבדיקות, אחראי למענה מהיר על שאלות.

לפי הנתונים האלה נפרק את העבודה לשלבים, נציין סיכונים ונקודות בקרה — ונדון במשימה באופן ענייני.