השוואה מערכתית
הרשאות API ב־Bybit, Bitget ו־MEXC: קריאה, מסחר ומשיכה
מפתח API צריך להתאים למשימה ולמשפחת הממשק. השוו הרשאות, מגבלות IP ותחולת חשבון, והפרידו תיעוד נתונים מיכולת לבצע או להעביר נכסים.
Bybit, Bitget ו־MEXC: API הוא הרשאה למשימה
מפתח API אינו ״חיבור טכני״ נטול משמעות פיננסית. הוא מעניק לתוכנה יכולת לקרוא מידע ולעיתים לשנות מצב חשבון, לשלוח פקודות או להזיז נכסים. Bybit, Bitget ו־MEXC מתעדות הרשאות וממשקים שונים, ולכן הבחירה מתחילה במשימה: איסוף היסטוריה, ביצוע מסחר, העברה פנימית או משיכה ליעד חיצוני.
לתיעוד עסקאות נדרשות הרשאות נתונים מתאימות; אין סיבה להסיק שנדרשת משיכה. לביצוע פקודות נדרשת יכולת מסחר, אבל היא מוסיפה סיכון גם כשהכסף אינו יכול לצאת מהחשבון. פעולה שמחליפה נכס או פותחת חשיפה יכולה לגרום להפסד בלי להשתמש בנקודת קצה למשיכה.
השוואה נכונה מתייחסת למשפחת ה־API ולסוג החשבון. Bybit V5, Bitget Classic או UTA ו־MEXC Spot V3 אינם שמות לאותו מסך. הרשאה שתועדה בממשק אחד אינה אישור שהיא מופיעה באותו אופן בממשק אחר, ואין להסיק מתיעוד ספוט על זכאות למסחר בחוזים.
אפשר להתחיל בסקירת Bybit, סקירת Bitget וסקירת MEXC. המאמר הזה ממקד את ההחלטה ביכולות החיבור ובבקרה עליו. לא נוצר מפתח, לא נקראו פרטי חשבון ולא נשלחה בקשה מאומתת במהלך המחקר.
ארבע יכולות API: מידע, פקודה, העברה ומשיכה
הרשאות שונות משפיעות על דברים שונים בחשבון. קריאה יכולה לחשוף יתרות והיסטוריה. מסחר יכול ליצור או לבטל פקודות. העברה יכולה להזיז נכס בין חשבונות או ארנקים בתוך השירות. משיכה יכולה לשלוח נכס לכתובת חיצונית בהתאם לתנאי נקודת הקצה. אין להסתפק בתיבה אחת בשם ״מופעל״.
אפשר לגלול את הטבלה לרוחב כדי לקרוא את כל העמודות.
| יכולת מתועדת | Bybit V5 |  Bitget | MEXC Spot V3 |
|---|---|---|---|
| בדיקת הרשאות | readOnly ורשימות permissions | קריאה מול כתיבה לפי Classic או UTA | מידע מפתח עם רשימת הרשאות ומצב |
| מסחר | קבוצות Spot ו־ContractTrade | Trade או UTA trade לפי משפחה | הרשאות עסקה לפי הממשק |
| משיכה | Wallet Withdraw בחשבון ראשי | הרשאת Withdraw ב־Classic | SPOT_WITHDRAW_WRITE בנקודת המשיכה |
הטבלה אינה מבטיחה שכל יכולת זמינה לכל לקוח. היא מתארת תחולה בתיעוד. ב־Bybit צריך להבחין בין חשבון ראשי למשני; ב־Bitget בין משפחות ממשק; ב־MEXC בין ממשק ספוט ותנאי החשבון. אפשרות שמתוארת במסמך אינה הזמנה לעקוף הגבלה.
גם ״העברה״ אינה שם חלופי למשיכה. חיבור עם יכולת העברה פנימית יכול לשנות את מיקום הכסף ואת זמינותו למוצר אחר. לכן צמצום הרשאות דורש רשימת פעולות נחוצות, ולא רק ביטול של תיבת משיכה והנחה שכל יתר האפשרויות חסרות סיכון.
Bybit V5: readOnly ורשימת ההרשאות צריכים להיבדק יחד
Bybit מתעדת נקודת בדיקה שמחזירה מידע על המפתח, ובה שדה readOnly וקבוצות הרשאות. קבוצות כוללות מסחר ספוט, מסחר בחוזים ופעולות Wallet. התיעוד מבחין גם בין חשבון ראשי למשני, ומציין שהרשאת Withdraw של קבוצת Wallet מתייחסת לחשבון ראשי. אלה תנאי תחולה, לא סיסמה כללית ש״כל API מאפשר משיכה״.
במפתח שמיועד להיסטוריה, בדקו שהמצב הוא קריאה ושהנתונים הדרושים כלולים. אם חסרות פעולות מסוימות, הרחבת יכולת מסחר אינה פתרון אוטומטי: הבעיה יכולה להיות כיסוי נקודת קצה, תקופת היסטוריה או חשבון משני שלא צורף. רשמו איזה מידע נדרש לפני שינוי הרשאות.
התיעוד מחזיר גם פרטי IP ותוקף לפי תנאי המפתח. אין במאמר מספר ימים אחד שחל על כל סוג מפתח או שירות מחובר. תוקף שמופיע במסך המפתח ובתיעוד סוגו חשוב יותר מהנחה כללית שמבוססת על חיבור אחר.
לפני חיבור לשירות חיצוני שמרו את שם החיבור, מטרתו והחשבון שאליו הוא שייך, בלי להכניס את הסוד לקובץ שיתופי. כשמפסיקים להשתמש בו, בדקו את ביטול הגישה במערכת הבורסה. הסרת שם השירות מהמסמך האישי אינה ביטול הרשאה פעילה.
Bitget Classic ו־UTA: שמות דומים, תחולה שונה
בתיעוד Classic של Bitget קיימת הבחנה מפורשת בין קריאה, מסחר, העברה ומשיכה. בתיעוד UTA מופיעות הרשאות קריאה וכתיבה למסחר ולהגדרות חשבון מאוחד. יכולת ניהול יכולה לשנות פרמטרים כגון מצב החזקה או מינוף, ולכן היא אינה רק ״מידע נוסף״ לתוכנה.
אל תעתיקו טופס הרשאות של חיבור Classic לתהליך UTA בלי לבדוק את התמיכה. גם מספר המפתחות והכותרות בתיעוד שונים בין המשפחות, ולכן ההשוואה אינה מציגה מגבלה אחידה לכל Bitget. השאלה היא מה המפתח המסוים יכול לעשות במשפחת הממשק שהשירות החיצוני משתמש בה.
Bitget מתעדת שלושה פרטי חיבור נפרדים: APIKey, SecretKey ו־Passphrase. ה־Passphrase של API אינה סדרת שחזור ארנק. היא גם אינה משהו שצריך להעתיק למאמר, צילום מסך או פנייה ציבורית. אם פרטי המפתח אבדו או נחשפו, משתמשים בתהליך הניהול המתאים ולא מנחשים אותם.
למשיכה ב־Classic מתועדת דרישה למקור IP ברשימה המאושרת. גם כאשר יש כלל כזה, הרשאה עודפת עדיין אינה מוצדקת לתוכנה שמבצעת רק דיווח. התאמת הרשאות למטרה ובדיקת מקור הבקשות משלימות זו את זו; אחת אינה תחליף לאחרת.
MEXC Spot V3: הרשאות מפורשות והגבלת זוגות
MEXC Spot V3 מתעדת מידע שוק, חשבון, היסטוריה ושליחת פקודות, לצד נקודות קצה של ארנק. בבדיקת מפתח מופיעים מצב, הרשאות, רשימת IP ותוקף. לנקודת המשיכה החדשה נדרשת הרשאה מפורשת בשם SPOT_WITHDRAW_WRITE. קריאת היסטוריה ומשיכה הן לכן יכולות שונות שאפשר לזהות בתיעוד.
ברשימת ההרשאות של עמוד מידע המפתח קיימת אי־אחידות בין חלק מהתיאור לדוגמת התשובה. במקום להסתמך על היעדר שם בתיאור ולהכריז שאין משיכה, משתמשים בדרישת ההרשאה של נקודת המשיכה עצמה. כך שומרים על טענה צרה ונתמכת בלי להשלים רשימה מזיכרון.
התיעוד מאפשר להגדיר זוגות מסחר למפתח. אפשרות כזאת רלוונטית לתוכנה שמורשית לפעול רק במשימה מוגדרת, אבל אינה מבטלת את הסיכון בפעולות המותרות. צמצום לזוג אחד אינו הגבלת הפסד מובטחת, וגם בתוך זוג נתמך יכולה להישלח כמות שגויה.
זהו מחקר של Spot V3, ולא אישור שהקורא יכול להשתמש ב־API חוזים או שבכל חשבון זמינות אותן הרשאות. מספרי תוקף וקצב קריאה תלויים בהגדרות ובנקודות הקצה, ולכן צריך לבדוק את המסמך של הפעולה המתוכננת. תיעוד ציבורי מסביר יכולת; הוא אינו מחליף בדיקת תנאי חשבון.
מקור IP ותוקף מפתח: ההגנה התפעולית ב־API
רשימת IP מאושרת מגבילה מאיפה ניתן להשתמש במפתח לפי כללי המוצר. היא אינה קובעת אילו פעולות מותרות, ואינה מבטיחה שהשרת המאושר לא נפגע. אם תוכנה פועלת משרת קבוע, בדקו את כתובת היציאה שלה; כתובת פנימית במחשב אינה בהכרח הכתובת שהבורסה רואה.
שירות חיצוני יכול להשתמש במקורות יציאה משתנים. דרישת IP שפורסמה לפני זמן רב אינה בהכרח רשימה תקפה היום. ודאו שהוראות השירות והבורסה מתיישבות, ואל תרחיבו באופן אוטומטי את הרשימה כדי להעלים שגיאת חיבור. חיבור לנתונים רגישים דורש הבנה גם של מקור הקריאה.
MEXC מתעדת תוקף למפתח שלא נקשר ל־IP ואפשרות חידוש לפי תנאים. Bybit מחזירה תוקף לפי מצבי מפתח שונים, ו־Bitget ממליצה על קשירה ל־IP. אין מכאן כלל זהה לשלוש הבורסות. רשמו את התוקף וההתראות של המפתח המסוים, כך שכשל סנכרון אינו מתפרש מיד כהיעדר פעילות.
כשמשנים שרת, ספק תוכנה או משפחת חשבון, בודקים מחדש גם הרשאות וגם מקור. מעבר טכני אינו סיבה לשמור מפתח עם יכולות ישנות שאינן נחוצות עוד. ביטול גישה לא בשימוש מצמצם תלות מתמשכת, בלי ליצור הבטחה שכל סיכון הוסר.
חיבור לדוחות מול חיבור למסחר: הרשאות לפי תוצר
לתוכנה שמרכזת רשומות צריך להגדיר איזה סוג מידע היא קוראת: מילויים, תנועות, עמלות או יתרות. אלה אינם בהכרח אותם נתונים באותה נקודת קצה. מפתח לקריאה יכול להיות תקין מבחינת הרשאות ועדיין לא לספק תקופה ישנה או מוצר שלא נכלל בחיבור.
לתוכנה שמבצעת פקודות צריך להגדיר גם מה מותר לה לשנות. מסחר, ביטול פקודות, מצב פוזיציה והעברה בין חשבונות הם פעולות שונות. אין צורך להפעיל יכולת משיכה כדי שתוכנה תוכל לגרום להפסד, ולכן בדיקת ״ללא משיכה״ אינה ביקורת מספקת של אוטומציה.
הפרידו מפתח דיווח ממפתח פעולה כשזה מתאים לתהליך ולתמיכה. ההפרדה מאפשרת להסביר מה כל שירות רשאי לעשות ולבטל אחד בלי להסתמך על שם עמום. היא אינה דורשת לפתוח חשבון חדש, ואין בה הבטחה שמשתמש או שרת לא יטעו.
לפני חיבור כתבו תוצר צפוי שאפשר לבדוק: איזה קובץ או רשומה אמורים להתקבל, או איזה מצב פקודה אמור להשתנות. השוואת Koinly לדוחות בורסה מסבירה למה סנכרון נתונים והיסטוריה מלאה הם שאלות שונות. כשהתוצר ברור, קל יותר לזהות הרשאה עודפת או פער כיסוי בלי לנחש.
תמחור והיסטוריה דרך API: לא להעתיק תנאי אתר
שימוש ב־API אינו רק דרך אחרת ללחוץ על אותו כפתור. הוא יכול להיחשף לנקודות קצה, תקופות היסטוריה ותעריפים שונים לפי מוצר וחשבון. לכן מחירון שנראה באתר אינו אישור שמערכת חיצונית תקבל את אותו חיוב, וחיבור שסיים קריאה אינו הוכחה שהוא הביא את כל הרשומות.
ב־Bitget יש פער בין תעריף ספוט כללי בעזרה לבין נתון ציבורי של זוג BTCUSDT. זה אינו מוכיח מהו החיוב האישי ב־API, אבל הוא מדגים למה מקור נתון ותחולתו צריכים להישמר. לפני תכנון מסחר מאומת בודקים תעריף חשבון ומוצר, ולא מייחסים למפתח את המספר הנוח יותר.
בהיסטוריה בדקו את מועד ההתחלה, את החשבון הראשי והמשני ואת סוגי הפעולות שנקראו. תוכנה שמחזירה רק יתרה אינה תחליף לקובץ רכישות. תוצאה ריקה יכולה להיות חוסר נתונים, טווח לא מתאים או שגיאה, ולא בהכרח היעדר פעילות.
לדיון במחיר ולא בהרשאות, השוואת Bitget מול MEXC ומדריך עמלות MEXC מפרידים מוצר וערוץ ביצוע. המאמר הנוכחי אינו מוסיף תעריף API חדש; הוא דורש שיכולת, כיסוי ועלות ייבדקו כשאלות נפרדות.
בדיקת חיבור ושגיאה: לא להרחיב הרשאות כדי לנחש
כשחיבור נכשל, התחילו במשמעות השגיאה ובתנאי נקודת הקצה. אימות, חתימה, תוקף, מגבלת קצב, IP וסוג חשבון הם סיבות שונות. הרחבת הרשאות בלי לזהות את הסיבה יכולה להוסיף סיכון בלי לפתור את הבעיה. גם הודעת הצלחה של בקשה אחת אינה אישור שכל הפעולות שהשירות צריך זמינות.
בדקו שהממשק והחשבון תואמים לתיעוד של החיבור. ב־Bitget Passphrase היא חלק מפרטי האימות של הממשק המתועד; ב־MEXC וב־Bybit יש כללי בקשה משלהן. אין להעתיק כותרות או מזהי מוצר בין ספקים כאילו מדובר בתקן אחיד.
שמרו לוג עם זמן, סוג בקשה, מצב ותיאור שגיאה, תוך הסרת סודות ומידע אישי. אין צורך לפרסם מפתח או גוף בקשה שמכיל פרטי חשבון כדי להסביר לתמיכה מה קרה. מזהה חיבור פנימי ושאלה ממוקדת יכולים להספיק לתחילת הבירור.
בחיבור שמבצע פעולות, הודעה עמומה דורשת בדיקת מצב לפני ניסיון חוזר. בקשה יכולה להתקבל גם אם האישור לא הגיע ללקוח. שליחה חוזרת ללא בדיקה עלולה להכפיל פעולה. זו דרישת תהליך לאוטומציה, ולא טענה שנבדקה כאן בקוד של ספק מסוים או בשירות מסחר פעיל.
מחיקה, החלפה ובחירת API: יכולת שנשארת רק כל עוד צריך
אחרי סיום שימוש בתוכנה, בדקו שהגישה בוטלה בבורסה ולא רק שהאפליקציה נמחקה מהטלפון. כשמפתח נחשף, תיעוד הספקים מנחה למחוק או להחליף אותו לפי המנגנון המתאים. מפתח שהיה נחוץ למשימה ישנה אינו צריך להישאר פעיל רק משום שהסנכרון הפסיק לרוץ.
במעבר למפתח חדש, שמרו את מפת החשבון וההרשאות והבינו מתי מפסיק הישן. בחיבור נתונים בדקו שאין חפיפה שמוסיפה אותן רשומות פעמיים. בחיבור פעולה בדקו שלא פועלים שני תהליכים על אותה משימה. מעבר הרשאות צריך להיות מתועד, לא רק שינוי ערך בקובץ.
Bybit V5 מתאימה לבדיקה דרך פרטי המפתח וקבוצות ההרשאות שלה; Bitget דורשת תשומת לב למשפחת Classic או UTA ולסוג יכולת הניהול; MEXC Spot V3 מאפשרת בדיקת פרטי מפתח וזוגות במסגרת התיעוד שנבחן. זו התאמה לתהליך, לא דירוג כולל של API טוב או בטוח יותר.
בחרו חיבור שאפשר להסביר: איזה מידע נקרא, איזה מצב משתנה, מאיזה מקור, ובאיזה תנאי מסתיימת הגישה. זכאות לחשבון, עלות המוצר ושלמות ההיסטוריה נבדקות לצד ההרשאות. שמירת הגבולות האלה מאפשרת להשתמש באינטגרציה בלי להציג יכולת טכנית כיתרון פיננסי או כהבטחת אבטחה.
