WeCore
אוטומציה

חיבור TradingView לברוקר: המדריך המלא מהרעיון ועד הפקודה

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

WeCore·פורסם ·8 דק׳ קריאה

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

הארכיטקטורה בתמונה אחת

חמישה רכיבים, משמאל לימין:

  1. מקור האות. אסטרטגיה או אינדיקטור שרצים על גרף ב-TradingView.
  2. התראה. מנגנון ההתראות של TradingView, שמחליט מתי לשלוח ואיזה טקסט לשלוח.
  3. Webhook. בקשת HTTPS משרתי TradingView לכתובת שבחרתם.
  4. גשר. תוכנה שמקבלת את ההודעה, מאמתת אותה, מפעילה את כללי הסיכון שלכם, מתרגמת לחוזה הנכון וקובעת את גודל הפקודה.
  5. API של הברוקר והחשבון. הממשק שדרכו הפקודה מגיעה לחשבון אצל הברוקר או ה-prop firm, ושם בפועל נעשה המילוי.

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

החלטה 1: התראת אינדיקטור או התראת אסטרטגיה

זה הפיצול הראשון, והוא משנה את ההתנהגות בכל השלבים הבאים.

התראת אינדיקטור או תנאיהתראת אסטרטגיה
מתי נוריתתנאי בגרף מתקייםמנוע האסטרטגיה מייצר פקודה
תוכן ההודעהכל טקסט שתכתבו, או הודעה מקוד Pineאפשר להשתמש ב-placeholders של הפקודה, למשל `{{strategy.order.action}}` ו-`{{strategy.order.contracts}}`
מודעות לפוזיציהאין, ההתראה לא יודעת מה הפוזיציה שלכםמכירה את `{{strategy.market_position}}` ואת `{{strategy.position_size}}`
סיכון טיפוסיאותות כפולים או חסרים אם לא תכננתם יציאותהתנהגות שונה מהבקטסט אם ההגדרות שונות

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

מה TradingView דורשת

לפני שמתכננים משהו, אמתו את הנקודות האלה בעמודים הרשמיים של TradingView (נקראו ב-11 באוקטובר 2026):

  • webhooks דורשים אימות דו-שלבי בחשבון ה-TradingView.
  • מתקבלים רק פורטים 80 ו-443 בכתובת.
  • בקשה שנמשכת יותר מ-3 שניות מבוטלת, ולכן הצד המקבל צריך להשיב מהר ולבצע את העבודה האיטית אחר כך.
  • IPv6 אינו נתמך.
  • TradingView מציינת ש-webhooks עלולים לפעמים לא להגיע לכתובת, כלומר המסירה אינה מובטחת.
  • הודעת JSON תקינה נשלחת כ-application/json, וכל דבר אחר כ-text/plain.
  • TradingView מפרסמת רשימת כתובות IP שמהן יוצאות הבקשות, שאפשר להתיר בצד המקבל.
  • התראות רגילות פגות (מקסימום חודשיים), ואילו בתוכניות Premium ו-Ultimate אפשר ליצור התראות בלי תפוגה. התראה שפגה פשוט מפסיקה לשלוח.

סטטוס המסירה של כל webhook נראה ביומן ההתראות, וזה המקום הראשון לבדוק בו כשלא מגיע כלום. במאמר על webhooks של TradingView יש עוד מלכודות אמינות כלליות.

החלטה 2: עיצוב ההודעה

ההודעה היא החוזה בין TradingView לגשר. הודעה טובה היא מפורשת ומשעממת.

מה ההודעה צריכה לשאת

ב-WeCore ההודעה היא JSON עם השדות: `ticker` (או `symbol`), `action` (buy, sell, exit, add, cancel, breakeven או protect), `quantity`, `orderType`, `limitPrice`, ובאופן אופציונלי אובייקטים `stopLoss` ו-`takeProfit` עם המרחק בנקודות. גשרים אחרים משתמשים בשמות שדות אחרים, ולכן תמיד העתיקו את התבנית מהתיעוד של הגשר שבו אתם משתמשים.

שלושה הרגלים שעוזרים:

  • הצהירו על הכוונה. יציאה צריכה לומר שהיא יציאה. אל תסיקו "סגירה" מ-sell ומגודל פוזיציה שאתם מניחים.
  • placeholders לערכים שמשתנים, קבועים לכל השאר. placeholder ממלא את הפעולה או הגודל ברגע השליחה; את הסימול וסוג הפקודה אפשר לכתוב פעם אחת.
  • בדקו ביומן. פתחו את יומן ההתראות, קראו את ההודעה שנשלחה בפועל והשוו אותה שדה אחר שדה למה שהגשר רשם.

אם קוד ה-Pine שלכם בונה ושולח את ההודעה בעצמו, שדה ההודעה של ההתראה אינו מקור האמת, אז החליטו מי מהשניים הוא ושמרו על זה.

החלטה 3: סימולים וחוזים

לחוזים עתידיים יש חודשי פקיעה. סימול רציף ב-TradingView כמו NQ1! עוקב אחרי החוזה הקרוב, אבל ברוקר סוחר בחוזה עם תאריך. או שהגשר מתרגם, או שאתם מתחזקים את ההתראה בעצמכם. WeCore מקבלת טיקרים רציפים כמו MNQ1!, MES1!, MGC1!, NQ1!, ES1! ו-GC1! ומתרגמת אותם אוטומטית לחודש הקרוב, כך שאין צורך לעדכן התראה בכל גלגול. רקע על הסיבה לגלגולים יש במאמר על גלגול חוזים עתידיים.

הטעות שאף גשר לא יכול לתקן במקומכם היא מיני מול מיקרו. NQ ו-MNQ, או ES ו-MES, שונים פי עשרה בשווי לנקודה. קראו על מיקרו מול מיני וכתבו את הסימול במכוון; פוזיציה "גדולה פי עשרה" כמעט תמיד נובעת מאות אחת.

החלטה 4: סוגי פקודות, סטופים ויציאות

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

להגנה, החליטו איפה הסטופ גר:

  1. בהודעה, כמרחקי `stopLoss` ו-`takeProfit` בנקודות, כך שהפקודות המגנות יוצאות יחד עם הכניסה.
  2. כברירת מחדל בגשר, לפי אסטרטגיה, עם אפשרות לאפשר להתראה לדרוס אותה או לא.
  3. רק בראש. זו האפשרות להימנע ממנה, כי כניסה אוטומטית בלי סטופ היא פוזיציה שאף אחד לא משגיח עליה.

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

שכבת הסיכון

הגשר הוא המקום שבו כותבים את הכללים שאף סקריפט בגרף לא יאכוף. לכל הפחות:

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

ב-WeCore אלה מוגדרים לכל חשבון באזור Risk, ואי אפשר להפעיל מסחר חי לפני ששמרתם אותם לפחות פעם אחת. כללים לחשבון prop צריכים לשבת בתוך הגבולות של החברה ולא בדיוק עליהם; ראו מגבלת הפסד יומי.

בדיקה בסימולציה

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

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

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

מעקב ותרחישי כשל

אוטומציה נכשלת בשקט, אז רשמו את הכשלים מראש.

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

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

בדיקת מדיניות ה-prop firm

היכולת לחבר חשבון אינה רשות לבצע בו אוטומציה. המדיניות שונה מאוד בין חברות ומשתנה, ולכן קראו את העמוד הרשמי של החברה לשלב החשבון שבידיכם, כולל כללים על שרתים מרוחקים ועל מסחר בתדירות גבוהה. ההשוואה המקורית נמצאת בחברות prop שמאפשרות אוטומציה, ומבנה הכללים הרחב בסקירת הכללים של Apex, Topstep ו-Lucid. אם משהו לא ברור, שאלו את החברה בכתב ושמרו את התשובה.

רשימת בדיקות לפני מעבר לחי

בדיקהמוכן כאשר
דרישות TradingViewאימות דו-שלבי פעיל, התוכנית תומכת ב-webhooks, ההתראה לא קרובה לפקיעה
סוג ההתראההתראת אינדיקטור או אסטרטגיה נבחרה במכוון, ונוצרה מחדש אחרי כל עריכה
ההודעהJSON תקין, פעולה מפורשת, סימול וגודל נכונים, נבדקה ביומן ההתראות
כתובת webhookסודית, שמורה היטב, הוחלט לגבי הגבלת IP
סוג פקודהלימיט עם מחיר, או שוק שנבחר מתוך ידיעה
סטופ ויעדאומת בבדיקה שהם מופיעים אצל הברוקר
כללי סיכוןנשמרו: הפסד יומי, גודל, פוזיציות, סימולים, שעות
סימולציהכמה ימים, כל התראה הותאמה לאות
מעקבהתראות פעילות, החיבור נבדק בכל סשן
מדיניות ה-prop firmנקראה לשלב החשבון שלכם, תשובה בכתב שמורה

לאן ממשיכים

אם אתם מעדיפים נקודת פתיחה מוכנה במקום לכתוב אסטרטגיה בעצמכם, אפשר להסתכל על אסטרטגיות מוכנות של WeAlgo, שרצות על שרת המסחר שלכם עם נתוני הברוקר שלכם. ואם אתם מעדיפים לחבר התראות TradingView משלכם, אפשר לראות את התוכניות והמחירים או לפתוח חשבון ולהריץ התראה ראשונה בסימולציה. ניסיון של 7 ימים מתחיל באימות כרטיס של $1, ושום דבר לא עובר לחי עד ששמרתם כללי סיכון וכיביתם את הסימולציה בעצמכם.

שאלות נפוצות

האם TradingView יכולה לשלוח פקודות ישירות לברוקר?

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

האם צריך תוכנית בתשלום ב-TradingView בשביל webhooks?

לפי מרכז העזרה של TradingView, webhooks דורשים אימות דו-שלבי בחשבון, והזמינות תלויה בתוכנית. בדקו את עמודי המחירים וההתראות העדכניים של TradingView לפני שבונים.

למה ההתראה נורתה ולא הופיעה פקודה?

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

פקודת שוק או פקודת לימיט?

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

האם מותר להפעיל אוטומציה בחשבון של prop firm?

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

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

מקורות וקריאה נוספת