נתוני DepthFeed
הפניה ל-API

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

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

טווחי כיסוי ספר הזמנות 3 פלטפורמות, 7 נכסים (btc · eth · sol · xrp · doge · bnb · hype) ושווקי הקריפטו העולים/יורדים החוזרים שכל זירה מפעילה (5דק, 15דק, 1שעה, 4שעות, 24שעות, תלוי בזירה).

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

ספורט קיים בכל תוכנית — כל ממשק ה-REST: ספרי Polymarket ו-Kalshi, סיכויי ספורט, תוצאות ופציעות בכל הליגות הגדולות. מה שתוכנית בתשלום מוסיפה הוא ספר חי בעל השהייה נמוכה דרך WebSocket, ספר מקביל אחד ב-Quant ושלושה ב-Desk. קפוץ אל נקודות קצה ספורט.

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

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

כללים קנוניים

1. השתמש https://depthfeed.com/docs כמקור האמת לשמות נקודות קצה, שדות, מגבלות ושערי תוכניות.
2. בחר את נקודת הקצה שמתאימה למשימה: /v3/demo לדוגמה ללא מפתח, /v3/markets לגילוי, /v3/snapshots לספרים היסטוריים, /v3/stream לספרים חיים, /v3/sports/markets למיפוי ספורט, ו /v3/whoami למגבלות חשבון.
3. אל תניח שקילות חוצה פלטפורמות מ kind, תוויות, סדר מערך, או cross_venue_key. אשר contract_mapping.status=matched ותנאי ההסדר לפני טיפול ב- cross_venue_market_key כשווה ערך.
4. שמור null, חותמות זמן, מזהי פלטפורמה ומטא-דאטה חלקית. HTTP 200 וספירה כוללת אינם מוכיחים שהתגובה שלמה.
5. עקוב אחרי מצביעים לא שקופים עד has_more שקרי, שומר על מסננים קבועים לאורך ההליכה בדף.
6. לתיקונים, סקר updated_since, עדכן לפי זהות שוק או תנאי יציב, שמור על ביטולי null, כלול שווקים מפורשים, וחפיפה רק לאחר מעבר מוצלח.
7. לבדיקות חזרה, השתמש בעומק הצעה/ביקוש מלא וגדלים נחים. אל תתאר נתוני נקודת אמצע או מחיר אחרון כמילויים ניתנים לביצוע.
8. ציין אימות מצב, תוכנית, חלון היסטוריה, הגבלת קצב והנחות פלטפורמה. אם התיעוד אינו מאשר עובדה, סמן אותה כלא מאושרת.

חוזה תשובה

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

1. צור חשבון חינמי ומנפיק מפתח API מלוח המחוונים. מפתחות נראים כמו df_… ומוצגים פעם אחת.

2. בצע את הקריאה המאומתת הראשונה שלך:

curl https://api.depthfeed.com/v3/whoami \
  -H "Authorization: Bearer df_your_key_here"

3. התגובה היא מעטפת JSON. קטע זה מציג חשבון Quant; המגבלות שלך תלויות בתוכנית שלך:

{
  "data": {
    "user_id": "acct_…", "plan": "pro",
    "rps": 25, "rpm": 1000, "history_days": 30, "coins": "all", "sports": true,
    "bars": { "max_symbols_per_request": 8 }
  },
  "meta": { "request_id": "req_…", "timestamp": "2026-06-07T02:27:09.532Z" }
}

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

נקודות קצה עם אימות דורשות מפתח API. מסלולים ציבוריים כוללים /v3/health, /v3/overview ו /v3/demo. העבר בכל מקרה — שתי הסכימות מתקבלות:

# Authorization header (recommended)
curl https://api.depthfeed.com/v3/btc/markets -H "Authorization: Bearer df_your_key"

# or the X-API-Key header
curl https://api.depthfeed.com/v3/btc/markets -H "X-API-Key: df_your_key"

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

כל נקודות הקצה פועלות תחת נתיב בסיס יחיד עם גרסה:

https://api.depthfeed.com/v3

TLS נדרש (Let's Encrypt, HTTP/2). גרסת ה-API הנוכחית היא v3, בנוי לשוויון PolyBackTest (אותו מעטפה, דפדוף קורסור, וקוד שגיאה) מעל מערך הנתונים הכולל שלנו (3 זירות, 7 נכסים). ישן v1/v2 מרחבי שמות אינם מוגשים.

כל תגובה מוצלחת היא אותו מעטפה:

{
  "data": … ,                 // object (single) or array (list)
  "pagination": { … },        // present only on list endpoints
  "meta": { "request_id": "req_…", "timestamp": "2026-06-07T02:27:09.532Z" }
}

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

{
  "error": { "code": "INVALID_COIN", "message": "…", "details": { … } },
  "meta": { "request_id": "req_…", "timestamp": "…" }
}

כל תגובה — הצלחה או שגיאה — נושאת meta.request_id, מוחזר גם כ- X-Request-Id כותרת. ציין זאת בבקשות תמיכה.

התפצל על error.code — הוא יציב. סטטוס HTTP משתמע מהקוד.

403 HISTORY_LIMIT_EXCEEDED נושא details.max_history_days ו details.oldest_allowed. 429 גם מגדיר Retry-After ו- X-RateLimit-* כותרות.

מגבלות הן דלי אסימונים לכל משתמש עם שני חלונות: פר שנייה פרץ ו-פר-דקה מתמשך מקסימום. חריגה מכל אחד מחזירה 429 עם קוד ההתאמה ו Retry-After של 1 שנייה.

Explorer הוא בקשה אחת לשנייה, ללא הגבלה נפרדת לדקה. זו קצב, לא אישור פיצוץ: לולאה שרצה במהירות המרבית תבזבז את רוב הבקשות שלה על 429. קרא X-RateLimit-Remaining, או פשוט המתן שנייה בין קריאות.

ערכי rps/rpm המפורסמים הם מגבלות כניסה כלליות ל-REST, לא שיעורי אספקת ארכיון. צילומי מצב היסטוריים, אצוות הכוללות קריאות היסטוריות ונתיבים כבדים אחרים משתמשים בבקרות תחרותיות ואספקה נפרדות ברמת חשבון. בקרות אלו חלות בנפרד מדלי דלי הטוקנים הכללי ואינן משנות את חלון ההיסטוריה של התוכנית.

Explorer, Quant ו-Research מקבלים כרגע בקשת היסטורית אחת פעילה לכל חשבון. Desk מקבל 6 בקשות צילומי מצב היסטוריים מקבילות לכל חשבון דרך מאגר השאילתות הייעודי של Desk. חפיפה מחזירה 429 HISTORY_CONCURRENCY_LIMIT עם Retry-After: 2; נסה שוב רק לאחר בקשה פעילה מסתיימת. ערכי rps/rpm כלליים אין להשתמש בהם כדי להסיק מקביליות היסטורית.

קריאה היסטורית יכולה גם להידחות כאשר החשבון שלך עדיין בתוך ההקצבה שלו, מכיוון שמאגר השאילתות המשותף של הארכיון רווי. מקרה זה מחזיר 429 HISTORY_POOL_BUSY עם details.scope = "shared_pool" במקום "account". הסתעף על details.scope: על account, הורד את רמת הפרלליות; ב- shared_pool, הורדת הפרלליות לא תעזור — נסה שוב עם השהייה.

/v3/bars יש לה תקרת מקביליות משלה, עצמאית משני הבקרים למעלה. מעבר לה בקשה נדחית מיד עם 503 BARS_BUSY ו details.retry_after בשניות, במקום להמתין בתור — דחייה מהירה שניתן לנסות שוב שימושית יותר מהצלחה איטית שלא ניתן לתכנן לה. התייחס לזה בדיוק כמו 429: נסוג ונסה שוב את אותה בקשה. גם לברים יש שתי מגבלות שאינן מגבלות קצב כלל — גודל אצווה (402 SYMBOL_LIMIT_EXCEEDED) וטווח בקשה (400 WINDOW_TOO_WIDE) — שתיהן מתוקנות על ידי פיצול הבקשה, לא על ידי המתנה.

ראה תכניות וגישה ל-rps/rpm לכל דרגה.

תבנית שאילתות היסטוריות

שמור לא יותר מהקונקרנטיות המאושרת שלך בהיסטוריה פעילה. השתמש ב-bounded start_time וend_time, דפדוף קורסור, ו limit=1000; השמט include_count ובקש את הסולם המלא רק כשצריך. הוסף interval כאשר סדרת דגימה מופחתת מספיקה. DepthFeed הוא מוצר גישה מבוסס מדידה: קבצים בכמות גדולה, משלוח ארכיון לא מקוון, שכפול מסד נתונים, והעתקת ארכיון שיטתית אינם כלולים.

נקודות קצה לרשימה משתמשות ב-opaque סורקי keyset — O(1) בכל עומק. העבר ?cursor= מהדף הקודם של pagination.next_cursor; עצור כאשר has_more הוא false.

"pagination": {
  "next_cursor": "6274…",   // opaque; feed back as ?cursor=
  "has_more": true,
  "limit": 50,
  "count": 50,
  "total_count": 1284        // only when ?include_count=true
}

פרמטרי שאילתה נפוצים

מ/ל ו start_time/end_time הם אותו חלון. שתי האיות עובדות בכל מקום; אם בקשה נושאת את שניהם, start_time/end_time לנצח.

חותמות זמן מקבלות אחד משניהם מילישניות מאז האפוק (למשל. 1780774485780) או ISO-8601 (למשל 2026-06-07T02:27:09Z). כל ערך המגיע למסד הנתונים מאומת ובטוח מפני הזרקות. חלון ההיסטוריה של התוכנית נאכף בכל נקודת קצה של רשימה/צילום מצב: start_time מעבר לתשואות החלון 403; אחד מושמט נדחס לרצפת החלון.

דגימה נמוכה עם interval

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

# one snapshot per minute instead of the raw stored series
curl "https://api.depthfeed.com/v3/btc/markets/{id}/snapshots?interval=1m&include_orderbook=true" \
  -H "Authorization: Bearer df_your_key"

מקבל משך זמן: מספר שניות בלבד, או ערך עם יחידה — 30s, 1m, 5m, 15m, 1h, 4h, 1d — מ 1s ל 1d. הדליים מיושרים לאפוק, כך ש 1m מתיישר לגבולות דקות של שעון קיר. דפדוף סמן ו include_count חל על השורות המדוללות (total_count נהפך למספר הדליים). השמט אותו, העבר raw, או העבר 0 לרזולוציה מלאה. ערך לא מוכר מחזיר 400 INVALID_INTERVAL. עובד בכל נקודת snapshot — Polymarket, Kalshi, Limitless, PredictFun, Binance וספורט.

בחירת תקופות; אינו מבצע אינטרפולציה. דלי מופיע בתגובה רק אם ספר נלכד בתוכו. שעתיים ב ?interval=1m משתרע על גבולות דקות 121 אך מחזיר רק את הדקות שהכילו לכידה — בדרך כלל עשר עד שלושים בשוק שאינו מצוטט באופן פעיל. זה הרישום המלא לחלון, לא עמוד מקוצר.

מילוי הפערים עם fill=ffill

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

# a dense 1-minute grid: 121 rows for a 2-hour window, gaps and all
curl "https://api.depthfeed.com/v3/btc/markets/{id}/snapshots?interval=1m&fill=ffill&from=1788202800000&to=1788210000000" \
  -H "Authorization: Bearer df_your_key"

fill דורש interval; בפני עצמו מחזיר 400 INVALID_PARAMETER. הערכים המתקבלים הם ffill (גם previous, prev, true, 1) ו none (גם false, 0, ברירת המחדל). נתמך באותם נתיבים כמו interval. הרשימה, הטיק, הנר ו orderbook/latest הנתיבים אינם צריכים למלא רשת ומתעלמים מהפרמטר במקום לדחות אותו, כך שלקוח ששולח אותו בכל מקום עדיין מקבל 200 מהם.

השעה של השורה עצמה משתנה כשאתה מפנה fill פעיל. עם interval לבד השורה היא תפיסה אמיתית, לכן id ו time/timestamp הם הרגע שבו תועד — 04:37:59.926 לדלי 04:37. עם fill=ffill כל שורה מייצגת דלי, כולל אלה שנתפסו, כך ששדות אלה הופכים לגבול הדלי (04:37:00.000) ורגע הלכידה זז ל- as_of_ts. לא אובד דבר בשני הכיוונים, אך תרשים שמצויר משניהם יהיה מוזז עד אינטרוול אחד אלא אם תקרא את אותו שדה בשניהם. אם אתה צריך את הרשת ואת רגע הלכידה יחד, בקש fill=ffill וקרא as_of_ts.

קריאת שורה מלאה

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

טיימסטמפ הדלי ו as_of_ts קרובים אך לא שווים אפילו בתפיסה, כי התפיסה נחתה איפשהו בתוך הדלי ולא על גבולו: 2026-09-02T00:50:00.000Z עם as_of_ts של 2026-09-02T00:50:44.437Z הוא דקה אמיתית שהחזיקה ספר אמיתי.

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

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

ה- resolution חסום

כל תגובה שהשתמשה ?interval= נושא את ה resolution חסום, כך שתוכל להבדיל בין רשומת לכידה דלילה לדף מקוצר ללא בקשה שנייה.

"resolution": {
  "interval_secs": 60,
  "buckets_in_range": 121,   // minute boundaries the window spans
  "buckets_filled": 29,      // minutes that held a CAPTURE
  "rows_returned": 121,      // rows on this page
  "fill": "ffill",           // absent when fill is off
  "complete": true           // false while a next_cursor is outstanding
}

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

ארבע תוכניות שטוחות. ה plan שדה שמוחזר על ידי /v3/whoami הוא הערך הגולמי בעמודה הימנית.

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

מה Explorer מגיע אליו

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

משפחת הנתיבים היחידה ש-Explorer אינו יכול להגיע אליה היא טיקים, הזמינים רק ב-Desk בכל זירה ומחזירים 402 TICKS_NOT_IN_PLAN מתחת לכך. ממשק הדמו האנונימי — ללא מפתח כלל — מוגבל בנפרד לדוגמת BTC, והוא הדבר היחיד שמגיב 402 COIN_NOT_IN_PLAN.

עמודות rps/rpm הכלליות מתארות קבלת בקשות, לא סריקות ארכיון סימולטניות. מקביליות שאילתות היסטוריות ובקרות אספקה הן נפרדות. קריאות היסטוריות של Desk משתמשות בבריכת שאילתות ייעודית ל-Desk בלבד מבודדת מתנועת שאילתות תוכנית רגילה, ללא הסרת בקרות ברמת החשבון. הבריכה משותפת בין חשבונות Desk ואינה תשתית בבעלות לקוח או בלעדית לחשבון.

הגבלת גישה נאכפת בצד השרת:

• שווקים — כל תוכנית, כולל Explorer, מגיעה לכל מטבע, לכל זירה, ולספר ההזמנות המלא; מה שמדרג הוא קצב העברה, היסטוריה וטיקים, לא גישה.
• היסטוריה — חלון מחוץ לתוכנית שלך → 403 HISTORY_LIMIT_EXCEEDED; שדרוג מרחיב את החלון, לעולם לא את רשימת השווקים.
• ספורט — ה /v3/sports/* ממשק REST כלול בכל תוכנית; חלון ההיסטוריה של אותה תוכנית חל על שני הווינות.
• היסטוריה — start_time מעבר לחלון שלך → 403 HISTORY_LIMIT_EXCEEDED.
• ברים של מחירים — /v3/bars מציית לאותו חלון היסטוריה כמו עומק, ומגביל בנוסף סמלים לבקשה (3 / 8 / 16 / 32), שעליו מחזיר 402 SYMBOL_LIMIT_EXCEEDED.
• שידור — מגבלות חלות בזמן המנוי על /v3/stream; כל תוכנית משדרת כל זירה — Explorer מוגבל למנוי אחד בו-זמנית, רמות בתשלום מגדילות את הספירה.

בדיקת חיים, ללא אימות. מחזיר { status: "ok", service, time }.

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

שווקי Polymarket למעלה/למטה לפי מטבע, מחוברים למחיר הסגירה (מחיר פתיחה/סגירה, מנצח, נפח). {coin} אחד מ- btc · eth · sol · xrp · doge · bnb · hype.

מסננים: type (5דק/15דק/1שעה/4שעות/24שעות), resolved (true/false), בנוסף לפרמטרים רגילים של זמן + דפדוף.

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

{ "data": {
  "market_id": "2456720", "event_id": "566750",
  "slug": "btc-updown-5m-1780860300", "market_type": "5m",
  "start_time": "…", "end_time": "2026-06-07T19:30:00Z",
  "condition_id": "0xb7ce…",
  "clob_token_up": "15598…", "clob_token_down": "51823…",
  "btc_price_start": null, "btc_price_end": null,
  "winner": null, "final_volume": null, "final_liquidity": null, "resolved_at": null
}, "meta": { … } }

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

מסננים: ?q= (slug search), ?type=event לכל מה שאינו סולם עלייה/ירידה, בנוסף ?coin=, ?event= ו ?outcome=. השווקים כאן ממופים לפי CLOB asset_id (מזהה טוקן); העבר זאת ל- /v3/polymarket/{asset_id}/snapshots להיסטוריית עומק או /v3/polymarket/{asset_id}/ticks לסרט. שווקים לא קריפטו נושאים ריק base_asset — אין להם מטבע, ואנחנו לא ממציאים אחד.

כל שורה נושאת category ו tags. סולמות עלייה/ירידה הם crypto; כל שוק אחר לוקח את הקטגוריה שלו מתגי האירועים של הזירה עצמה, באותו כתיב כמו Polymarket US (ספורט, crypto, politics, geopolitics, finance, macro, technology, science, climate, culture), עם תגי הסלאג הגולמיים ב- tags ו null כאשר לזירה אין תווית. סנן עם ?category=politics,macro או ?exclude_category=sports,crypto: מופרד בפסיקים, לא תלוי רישיות, ניתן לשלב; החרגה שומרת על שווקים ללא תווית. ?closed=true|false הוא דגל המסחר של המקום (סולם נסגר ברגע ש- end_time עבר). עבור מראה, ?updated_since= (ISO-8601, תאריך או מילישניות אפוק) מחזיר רק שורות שהתוכן, התווית או מצב הסגירה שלהן השתנו מאז אותו זמן; כל שורה updated_at הוא אותה חותמת. resolved אינו מסנן בנתיב זה ומדווח תחת meta.ignored_params.

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

טייפ המקום הרחב עבור אותו asset_id מפתחות.

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

הוסף ?include_orderbook=true לקבל את כל הסולם (נמחק כברירת מחדל עבור משקל קל יותר). חלון זמן + דפדוף עם סמן. הוסף ?interval=1m (או 5m, 1h, …) לדגום מחדש לספר אחד לכל דלי במקום הסדרה הגולמית המאוחסנת — ראה דפדוף ומסננים. תגובת הרשימה היא מערך עם pagination חסום:

{ "data": [{
  "id": "1780774485780", "time": "2026-06-06 19:34:45.780",
  "market_id": "2456720", "btc_price": 60606.68,
  "price_up": 0.505, "price_down": 0.495,
  "orderbook_up":   { "bids": [[0.50, 304.25], …], "asks": [[0.51, 30.0], …] },
  "orderbook_down": { "bids": [ … ],               "asks": [[0.50, 304.25], …] }
}], "pagination": { … }, "meta": { … } }

צילום מצב יחיד הקרוב ביותר לחותמת זמן (בתוך ±2 שניות). {timestamp} הוא ms-epoch או ISO-8601. בניגוד לנקודת הקצה של הרשימה, data הוא אובייקט יחיד (אותו מבנה שורה) עם לא pagination חסום; אין התאמה בטווח של ±2 שניות מחזירה 404 SNAPSHOT_NOT_FOUND.

{ "data": {
  "id": "1780774485780", "time": "2026-06-06 19:34:45.780",
  "market_id": "2456720", "btc_price": 60606.68,
  "price_up": 0.505, "price_down": 0.495,
  "orderbook_up":   { "bids": [[0.50, 304.25], …], "asks": [[0.51, 30.0], …] },
  "orderbook_down": { "bids": [ … ],               "asks": [[0.50, 304.25], …] }
}, "meta": { … } }

רמות הן [price, size]. price_up הוא נקודת האמצע של ההצעה/הבקשה הטובה ביותר; price_down = 1 − price_up. ה orderbook_down הצד נגזר כהשלמה בינארית של ספר העלייה (down = 1 − up, גדלים נשמרים). מחיר המטבע הוא הטיק הקרוב הקודם באמצעות הצטרפות ASOF — מדויק ל-1שעה/4שעות/24שעות, פרוקסי מתויג של Binance ל-5דקות/15דקות.

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

נתיבי צילום מצב ווניו אחרים

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

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

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

לארגונים בלבד. תוכניות אחרות מקבלות 402 TICKS_NOT_IN_PLAN.

Polymarket, מקור מהזרם דלתא של CLOB. שני אסימוני התוצאה מוחזרים כברירת מחדל ומסומנים outcome; צמצם עם ?outcome=up או ?outcome=down.

היסטוריה: הטייפ רציף מ 2026-06-25 (נבדק 2026-09-02) וממשיך להצטבר, כך שהחלון האמין גדל ביום כל יום. ימים לפני כן קיימים בארכיון אך אינם רציפים — 61 מהם חסרים בין 2026-04-14 לבין הרצף הרציף — לכן בדיקת חזרה שדורשת סדרה רציפה צריכה להתחיל לא מוקדם מ-2026-06-25.

כיסוי: שווקי עלייה/ירידה ב 5m, 15m ו 24h חלונות, בכל שבעת הנכסים. ה 1h ו 4h משפחות למעלה/למטה הן לא כעת בסרט הטיקים — השתמש תמונות מצב לאלה.

{ "data": [{
  "id": "1780774485780", "time": "2026-06-06 19:34:45.780",
  "received_ms": "1780774485812", "outcome": "up",
  "token_id": "7194…", "side": "BUY", "price": 0.505, "size": 1240.0
}], "pagination": { … }, "meta": { … } }

חדש — לכידת טיקים של Kalshi החלה ב-2026-08-07. אין היסטוריית טיקים של Kalshi לפני תאריך זה; הטייפ מצטבר קדימה ממנו. Kalshi תמונות מצב נשארים זמינים לאורך כל חלון ההיסטוריה.

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

מקור מאומת מ- orderbook_delta WebSocket. kind הוא snapshot לשורות שמקשרות ספר (כך שכל חלון שתבקש מתחיל ממצב מלא) או delta לשינוי. delta הוא שינוי הגודל החתום ו- size הוא הגודל הנוח במחיר זה אחרי זה. seq הוא מספר הסידורי של Kalshi למפגש הלכידה — הוא עולה בדיוק באחד לאורך המפגש, כך שתוכל לוודא שרצועת הטייפ שלמה במקום להסתמך על דברינו. רצף של snapshot שורות מסמנות סשן חדש, שבו הוא מתחיל מחדש. צר למספר צד אחד עם ?side=yes או ?side=no.

שחזור ספר: לטפל בכל snapshot מריץ כאיפוס קשה של ספר השוק ההוא, ואז מיישם delta שורות ב seq סדר בתוך הסשן. סדר לפי seq, לא על ידי time: חותמות הזמן של הזירה עצמה אינן מונוטוניות בין רמות בתוך מילישנייה אחת, בעוד seq הוא. כל seq שלב שאינו +1 בתוך סשן הוא פער בטייפ לאותו קטע; הלכידה מתנתקת ומצלמת מחדש בעצמה בכל פעם שהיא מזהה אחד, כך שההבא snapshot הריצה היא הנקודה שממנה הספר שלם שוב.

{ "data": [{
  "id": "1780774485780", "time": "2026-06-06 19:34:45.780",
  "received_ms": "1780774485791", "seq": "418823",
  "kind": "delta", "side": "yes", "price": 0.62, "delta": -85.0, "size": 240.0
}], "pagination": { … }, "meta": { … } }

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

ספר הנכס הבסיסי וגליון המסחר מ-Binance. {venue} הוא spot או futures. הספר הוא 20 רמות לכל צד.

ספר היסטוריה אחרון / ספר היסטוריה בדפדוף. כל צילום: price (אמצעי), bids, asks, timestamp.

1-שניות OHLCV עם חלוקה אגרסיבית לקנייה/מכירה — מדויק, 1:1 עם ההתייחסות:

{ "data": [{
  "id": "1780747762000", "timestamp": "2026-06-06 12:09:22.000",
  "price_open": 61097.1, "price_high": 61097.1,
  "price_low": 61097.09, "price_close": 61097.1,
  "total_volume": 0.01667,
  "aggressive_buy_volume": 0.0156, "aggressive_sell_volume": 0.00107,
  "num_trades": 3
}], "pagination": { … }, "meta": { … } }

ברי מחיר OHLCV למניות ו-ETF אמריקאיות, זוגות ספוט Binance, וחוזים עתידיים מתמשכים. דקה היא הרזולוציה המדויקת ביותר; המסגרות הגסות מגולגלות ממנה.

symbols הוא רשימה מופרדת בפסיקים. timeframe אחד מ- 1Min, 5Min, 15Min, 1Hour או 1Day (ברירת מחדל 1Min). start_time, end_time, limit ו cursor מתנהגים בדיוק כפי שהם מתנהגים בכל אוסף אחר כאן.

id הוא חותמת זמן, לא מפתח ייחודי. הזנת העומק מגיעה כל 100 מילישניות והבורסה לעיתים חותמת שני ספרים שונים באותה מילישנייה, כך שדף יכול להחזיק חוקית שתי שורות עם אותו id ושני סולמות שונים. דפדוף מטפל בקשר — הסמן הוא keyset, כך שמילישנייה משותפת לעולם אינה מפוצלת על פני גבול עמוד — אך לקוח שממפה שורות לפי id לבד תשליך בשקט אחד משני. מפתח על השורה, או על (id, sequence within the page).

venue אופציונלי ובוחר את השוק ישירות: us-equities, binance (spot) או binance-futures (perpetuals). השאר כבוי וסימול יחיד יפורש עבורך — מניות קודם, ואז Binance spot. תן שם ותקבל את השוק הזה או כלום, שזה מה שאתה רוצה כאשר מחרוזת יכולה להיות שני מכשירים.

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

curl -H "X-API-Key: $DEPTHFEED_KEY" \
  "https://api.depthfeed.com/v3/bars?symbols=AAPL,BTCUSDT&timeframe=1Hour&start_time=2026-08-01T00:00:00Z"

{ "data": {
  "timeframe": "1Hour",
  "license_class": "source_attributed_public_serving",
  "attribution": "Market data via QuarterTrace. Source-attributed; not a consolidated (SIP) feed.",
  "series": [{
    "symbol": "AAPL", "timeframe": "1Hour", "assetClass": "equity",
    "source": "yahoo_finance", "derived": true,
    "t": [1785974400000, 1785978000000],
    "open": [306.83, 307.04], "high": [307.9, 308.1],
    "low": [306.1, 306.55], "close": [307.04, 307.8],
    "volume": [1043200, 887400]
  }]
}, "meta": { … } }

איך לאיית סמל

מניות ו-ETFs הן הטיקר הרגיל שלהן: AAPL, SPY, BRK-B. זוג קריפטו מאוית כפי שהזירה מאייתת אותו, כך שהוא BTCUSDT במקום BTC. חוזה עתידי מתמשך לוקח .P סיומת — BTCUSDT.P, AAPLUSDT.P — כי זוג הספוט והפרפ הם מכשירים שונים שמסחרים במחירים שונים, ומרחב סימנים שטוח שבשקט בחר אחד בשבילך היה בוחר איזה שוק האסטרטגיה שלך מדדה.

מסגרות נגזרות

מניות נאספות ב 1Min ו 1Day; קריפטו נאסף ב 1Min. כל דבר אחר מצטבר בקריאה, וסדרה מציינת מה היא עם derived. בר מצטבר לוקח את פתיחת הבר הראשון וסגירת הבר האחרון, את הקיצונים של הגבוה והנמוך, ואת סכום הנפח, על פני דליים מיושרים ל-UTC.

מגבלות

שלושה גבולות נפרדים, והם נכשלים עם שלושה קודי שגיאה שונים. חלון ההיסטוריה של התוכנית שלך חל כאן כמו בכל מקום אחר — מעבר לו, 403 HISTORY_LIMIT_EXCEEDED. סימולים לבקשה הם 3 ב-Explorer, 8 ב-Quant, 16 ב-Research, 32 ב-Desk; מעל לכך, 402 SYMBOL_LIMIT_EXCEEDED. ובקשה אחת יכולה לכסות רק את משך הזמן שמספר השורות במסגרת מאפשר — 45 ימים ב 1Min, 180 ב- 5Min, שנה ב- 15Min ו 1Hour, עשר שנים ב- 1Day — שעליו הוא מחזיר 400 WINDOW_TOO_WIDE. דפדף עם limit ו cursor ללכת בטווח רחב יותר ממה שבקשה אחת מכילה.

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

חוזי הקריפטו של Kalshi — עומק מלא של כן/לא שהייחוס אינו נושא. 21 סדרות לכל 7 הנכסים: 15-דקות KX{ASSET}15M, סף KX{ASSET}, וכיווני KX{ASSET}D. סף וסדרות כיווניות פועלות כל אחת בשווקים שעתיים, יומיים ושבועיים במקביל — market_type נושא את חלון השוק האמיתי של כל שוק.

מסננים: ?coin= (נכס בסיס), ?type= (חלון), ו ?series= (לדוגמה KXBTC15M). להורדות היסטוריות, העבר start_time ו end_time כאן תחילה והשתמש במזהי הטיקר המקומיים של המקום שהוחזרו. אל תייצר מזהי טיקר של Kalshi מתאריכי זמן UTC; קונבנציית שעון הטיקר של המקום השתנתה היסטורית.

ברירת מחדל הרשימה מוגבלת לשווקים שספר ההזמנות שלהם נלכד בתוך חלון התוכנית שלך, כך שכל שורה כוללת /snapshots. העבר ?include_uncaptured=true לקטלוג המלא של הפלטפורמה: כל סדרת Kalshi, ספורט, פוליטיקה, כלכלה, מזג אוויר ובידור כלולים. שורות אלה נושאות נרות, לא ספרים; depth_captured בשורה כלשהי מציין איזה סוג אתה מסתכל עליו.

כל שורה נושאת category, תווית הסדרה של הזירה עצמה (Politics, ספורט, קריפטו, Climate and Weather, …). סנן עם ?category=politics,elections או ?exclude_category=sports,crypto; שניהם מקבלים רשימות מופרדות בפסיקים, משווים ללא תלות באותיות רישיות, ועשויים להיות משולבים. השתמש ב category לזה, לא base_asset: base_asset נקרא מפריפיקס הסדרה ומשמעותי רק בשורות קריפטו.

ספר כן/לא מלא חדש ביותר עבור טיקר. yes/לא הם [price, size] מערכים (מחירים ב-0–1 דולרים).

{ "data": {
  "ticker": "KXHYPED-26JUN0717-T73.9999", "series": "KXHYPED",
  "base_asset": "hype", "market_type": "24h",
  "id": "1780…", "timestamp": "…",
  "yes": [[0.62, 1400], …], "no": [[0.38, 900], …]
}, "meta": { … } }

ה- היסטורי סדרת עומק כן/לא עבור טיקר שוק מדויק אחד שהתגלתה — אותו מבנה שורה, מסודר לפי זמן קבלה, חלון זמן + דפדוף עם סמן (include_count opt-in, מקסימום 1000). היסטוריית ספר Kalshi שנלכדה קדימה מלולאת סקר REST מתוזמנת. הקצב האפקטיבי משתנה עם קבוצת השווקים הפעילה ומגבלות הAPI; הוא משתמש באותו דפוס נקודת קצה היסטורית כמו Polymarket וLimitless /snapshots, כך שעומק Kalshi ניתן לבדיקה חוזרת גם כן. העברת סדרה כגון KXBTC15M, או טיקר היסטורי מומצא, מחזיר שגיאת גילוי מפורשת במקום דף ריק מטעה.

שעה OHLC של הצעת המחיר כן, בקשת המחיר כן והמחיר המסחר, בנוסף ל- volume ו open_interest. זו ההיסטוריה היחידה שקיימת עבור רוב קטלוג Kalshi: Kalshi אינה מספקת ספר הזמנות היסטורי, כך ששוק שנסגר לפני שהתחלנו ללכוד את הספר שלו אינו מכיל /snapshots ולא /ticks — אבל יש לו נרות, שמגיעים עד לשנה אחורה.

חלונות זמן ודפדוף עם סמן כמו /snapshots (מקסימום 5000 שורות), מוגבל לחלון ההיסטוריה של התוכנית שלך. ?interval= בוחר את תקופת הנר; רק 1h נרשם, וכל ערך אחר מחזיר שגיאה מפורשת שמציינת מה קיים במקום דף ריק. נרות מאוחסנים כפי שנרשמו ולעולם לא מדגמים מחדש, כך שתקופה קצרה יותר לעולם לא מסונתזת מתקופה ארוכה יותר.

price הוא null כאשר לא התבצע מסחר בתקופה — כ-95% מהם. צדדי הציטוט תמיד אמיתיים, כך ששעה שקטה עדיין מראה היכן עמד הספר. הכיסוי הוא שווקים ארוכי טווח (פתוחים לסגירה יותר מ-24 שעות); סולמות קריפטו קצרים נתפסים ברזולוציה מלאה על ידי /snapshots ו /ticks במקום זאת, ובקשת הנרות שלהם מחזירה 404 שזה אומר.

{ "data": [{
  "ticker": "KXFEDDECISION-26JUL-H26", "series": "KXFEDDECISION",
  "market_type": "1w", "id": "1786168800000", "timestamp": "…",
  "period_minutes": 60,
  "yes_bid": { "open": 0.56, "high": 0.58, "low": 0.55, "close": 0.57 },
  "yes_ask": { "open": 0.64, "high": 0.65, "low": 0.62, "close": 0.63 },
  "price":   { "open": 0.60, "high": 0.61, "low": 0.59, "close": 0.61 },
  "volume": 240, "open_interest": 1180
}], "pagination": { … }, "meta": { … } }

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

Polymarket US הוא שוק חוזים שמונה על ידי CFTC ופלטפורמה נפרדת מ-Polymarket: השווקים ממוקדים על slug, אין condition_id ולא asset_id, ושום דבר כאן אינו מצטרף למשטחי Polymarket למעלה. רק תוכניות בתשלום. זירה זו נמצאת בבדיקת חי: הקטלוג, המחירים והעסקאות מוגשים בכל קטגוריה, וכיסוי הספר עדיין מתרחב.

קטלוג המקום, כל קטגוריה, סגירה חדשה ראשונה ומדורג עם סמן. כל שורה נושאת את ה category (ספורט, crypto, politics, climate, culture, macro, technology, finance, geopolitics, science). סנן עם ?category=politics,macro או ?exclude_category=sports,crypto: מופרד בפסיקים, לא תלוי רישיות, ניתן לשלב. סינונים נוספים: ?coin=, ?type= (15m, 1h, futures, …), ?series=, ?closed=, ?resolved=, start_time/end_time על זמן הסגירה. עבור מראה, ?updated_since= מחזיר רק שורות שהתוכן שלהן השתנה מאז אותו זמן (רישום, סגירה, שינוי סטטוס); כל שורה updated_at הוא אותה חותמת. sports_market_type הוא שדה של המקום שהמקום גם ממלא מחוץ לספורט; הוא לא מבחין ספורטיבי, category הוא.

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

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

Limitless Exchange — CLOB על Base שמפעיל שווקי קריפטו חוזרים למעלה/מטה ב 5 דקות ו-15 דקות. העומק נלכד בזמן אמת דרך websocket של ספר ההזמנות שלו (כך שגם הספרים המהירים של 5 דקות מוקלטים). {slug} נראה כמו btc-up-or-down-15-min-1780798512077.

מקומות פתוחים נוכחיים. מסננים: ?coin= ו ?type= (5דק/15דק).

עומק L2 חדש ביותר עבור slug (bids יורדים, asks עולים):

{ "data": {
  "slug": "btc-up-or-down-15-min-1780798512077", "condition_id": "0x…",
  "base_asset": "btc", "market_type": "15m",
  "id": "1780798…", "timestamp": "2026-06-07 02:27:09.532", "midpoint": 0.5,
  "bids": [[0.45, 200.0], …], "asks": [[0.46, 120.0], …]
}, "meta": { … } }

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

שווקי תחזית קריפטו של ארנק Binance מגובים ב-Predict.fun, מנורמלים למרחב שמות ייעודי של DepthFeed. הקטלוג הראשוני כולל שווקי BTC, ETH ו-BNB up/down.

סנן עם ?coin=btc, ?type=5m, או ?status=resolved. התוצאות כוללות את מזהי השוק/נושא, תנאי ומטא-נתוני טוקן, החלטה, תוצאה מנצחת, נפח, נזילות, מספר משתתפים, שרשרת וחוזה החלפה.

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

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

התחל כאן לכל דבר חוצה פלטפורמות. המסנן עונה על השאלה המרכזית — איך אותו שוק “למעלה או למטה” מתומחר עכשיו ב-Polymarket, Kalshi ו-Limitless? — בתוך בקשה יחידה, כך שלעולם אינך מחבר את שלוש נקודות הקצה לזירה (עם שלושת המזהים השונים שלהם) בעצמך. כל תוכנית רואה את כל שלוש הזירות; חלון ההיסטוריה של התוכנית הוא ההבדל היחיד כשאתה עוקב אחרי תא להיסטוריה שלו.

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

{ "data": {
  "assets":  ["btc","eth","sol","xrp","doge","bnb","hype"],
  "windows": ["5m","15m","1h","4h","24h"],
  "cells": [{ "asset": "btc",
    "polymarket": { "up": 0.735, "down": 0.265, "best_bid": 0.73, "best_ask": 0.74, "price_to_beat": 62764.0 },
    "kalshi":     { "up": 0.71,  "down": 0.29,  … },
    "limitless":  { "up": 0.75,  "down": 0.25,  "slug": "btc-up-or-down-…", … } }],
  "paid": true
}, "meta": { … } }

חפור לתוך (נכס, חלון): ה ספר L2 מלא בכל פלטפורמה צד לצד (books.polymarket / books.kalshi / books.limitless), בנוסף לסדרת הספוט הבסיסית ולסגירה price_to_beat — הקריאה היחידה שסקר ארב או בדיקת חזרה חוצת-זירה באמת צריכים.

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

הרץ עד 10 GET /v3/ בקשות בנסיעה אחת. כל בקשה-משנה נשלחת באופן עצמאי ומקבלת סטטוס משלה.

curl -X POST https://api.depthfeed.com/v3/batch \
  -H "Authorization: Bearer df_your_key" -H "Content-Type: application/json" \
  -d '{ "requests": [
    { "id": "a", "method": "GET", "path": "/v3/btc/markets?limit=1" },
    { "id": "b", "method": "GET", "path": "/v3/limitless/markets?type=5m&limit=1" },
    { "id": "c", "method": "GET", "path": "/v3/bars?symbols=BTCUSDT&timeframe=1Hour" }
  ] }'

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

החזרות { data: [ { id, status, body }, … ] } עם חיצוני 200. מעל 10 בקשות משנה → 400 BATCH_TOO_LARGE; לא GET או לא/v3/ נתיב מקבל per-sub 400 BATCH_INVALID_PATH.

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

זהויות של מתקנים, מועמדים וחוזים

קיים kind, outcomes ו tokens נשארים מחרוזות פשוטות ילידות לוויניו; תוצאות וטוקנים מתיישרים לפי אינדקס בתוך שורה אחת. fixture_participants מספק משתתפי תחרות קנוניים בנפרד מסוג השוק. market_family ו market_period נרמול תוויות סוג נתמכות ללא הטענה של שורות, צדדים או חוקים שווים. תוויות כלליות כן/לא ויותר/פחות אינן מוקצות לקבוצה. חוזה Kalshi YES עם אסימון אחד נשאר אסימון אחד; השלמה NO שלו אינה אוטומטית היריב.

מועמדים לקו כסף מוערכים ברחבי ליגות כאשר ניתן לזהות תוצאה עם תווית fixture ושני משתתפים. השוואות חצי-יחידה מקוריות של מרווח, סך וסך-קבוצה משתמשות כעת ב-sports-lines-v1, contract_spec וצד לכל תוצאה. תקופות חצי/רבע מקוריות עוקפות תוויות סוג גנריות. הצעות ספירה מקוריות מפורשות יכולות לנרמל לגבולות חצי-יחידה כאשר המכה, המדד והנושא מסכימים. משחקי טניס/מערכות, משחקי esports/מפות, קרנות, טאצ'דאונים, שערי שדה ויארדים התקפיים שומרים על מדדים מובחנים. סך חמש הראשונות הן ריצות משולבות; תחומי אינינג נפרדים נשארים מובחנים. קווים של מספרים שלמים/דחיפה וחלוקה, מדדים לא ידועים, עתידיים ו-props אינם נתמכים; עיין בחוזה המיפוי לסמנטיקה של מרווח חתום. רישום הפרופיל הנוכחי אינו כולל זוגות שווים מאושרים; מפתחות מאומתים הם אפסיים. מפתחות מועמדים תומכים בקיבוץ נושא עם החלטת הסדר נבדקת בנפרד; אינם מחליפים שוויון מאומת. אין תאריך לתאימות מאושרת רחבה יותר.

הרמה העליונה cross_venue_market_key ו contract_mapping.cross_venue_market_key כינויים זהים ממיפוי אחד. קרא את הראיות המקוריות הנוכחיות עם GET /v3/sports/markets/{condition_id}/contract; ראיות חסרות הן null, וראיות שתוקפן פג או שאינן תואמות קלט מסומנות במפורש. GET /v3/sports/market-families מחזיר את מפתחות הסוג הקריא למכונה.

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

עבור Rams נגד 49ers, זהות המשתתף לבדה אינה פותרת סעיפי דחייה שונים. ראיות ואבחונים יכולים לפוג; קרא את קודי הסיבה הנוכחיים וראיות מקור במקום לקודד סטטוס לדוגמה.

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

מרווח רבעוני, סוגים כוללים סה"כ וסה"כ צוות מסווגים במפורש. מועמדים בינאריים מקוריים משתמשים ב sports-binary-v1 וגורם מפורש: לעולם אל תסיק משמעות מתווית כגון nrfi. תוצאות קו נתמכות מצטרפות לפי צד בתוך המועמד; תוצאות moneyline מצטרפות לפי משתתף. ראה מדריך ה-API לספורט לפרמטרי נקודת קצה ושדות תגובה לפני ביצוע צירופים מתמשכים.

גרעין שורה ומיון איכות נתונים

שורה אחת היא רשומת שוק קטלוג. כמה שורות moneyline של Kalshi מקבצות שני חוזי YES עצמאיים; רשומות אחרות חושפות חוזה אחד. אביזר יכול לייצר תוצאות moneyline נפרדות, פערים, סה"כ, סה"כ קבוצתי, props, וריאנטים של קו ורשומות תנאי היסטוריות, כך שספירות מקובצות לפי cross_venue_key לא צפויים להתאים בין פלטפורמות. הבדל גדול הוא אות לסקירה, לא הוכחה שחסרות או משוכפלות שורות.

resolved=false משמעותו שהמקום לא סמן את התנאי הזה כסופי; זה לא אומר שהמיפוי לא נפתר. שוק יכול להיות לא פתור עם מפתח מתקנים מועמד, או פתור עם מיפוי null או מבוטל. שמור resolved, contract_mapping.status ונוכחות מפתח כצירים נפרדים.

לביקורת, פרט league, scope ו kind עם GET /v3/sports/markets, ואז השווה שורות באותו חתימה מנורמלת: אירוע, תקופה, משתתף, קו, צד, סוג ופרופיל סגירה. השתמש ב- candidate_key לקבוצות מועמדים ו cross_venue_market_key רק להצטרפויות מאושרות. לעולם אל תמלא מפתח null מתוך slug, כותרת, מיקום במערך או יחס ספירת שורות; שמור reason_codes ומצב ראיות.

slugs של וונה יכולים להיות שונים עבור אותו אירוע. לדוגמה, Kalshi kalshi-soccer-ieloak-2026-09-20 ו-Polymarket uslc-iel-oak-2026-09-20 דורש בדיקות תחרות, משתתף, זמן התחלה והסדר לפני כל הצטרפות.

תיקונים הדרגתיים

/v3/sports/markets?updated_since= מקבל מילישניות אפוק, ISO-8601 או תאריך. updated_at ו updated_ms הם זמני פרסום קטלוג. זהות, פתיחת משחק, ביטולי מיפוי וחידושי ראיות מפרסמים עדכונים.

1. שמור את זמן התחלת הסקר ואת נקודת הביקורת הקודמת.
2. שמור updated_since וסינונים קבועים על פני כל סמן.
3. עדכון על ידי condition_id, כולל ערכים נללים שמבטלים מיפויים ישנים.
4. כלול שווקים שהוסדרו במהלך סקר תיקון.
5. התקדם מתחילת הסקר עם חפיפה רק לאחר שכל עמוד מצליח.

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

אימות תגובה

בדוק meta.partial אפילו אחרי HTTP 200. שמור מחירים null, עקוב אחרי סמני עכבר שקופים תוך כדי has_more אמת, ואל תתייחס לספירות או למטא-נתוני רזולוציה כהוכחה לשלמות כלל-מקום. שורות ממולאות קדימה הן תצפיות נישאות, לא לכידות חדשות.

זמן אמת ספורט נתוני שוק תחזיות — עומק ספר הזמנות חי ב-Polymarket ו-Kalshi, לצד סיכויי ספורט, תוצאות חיות, ופיד פציעות בליגות הגדולות (NBA, NFL, MLB, NHL, כדורגל, טניס, UFC, F1 ועוד). שני הווינויים כלולים יחד בכל רמה; התוכניות משנות את חלון ההיסטוריה המשותף, התפוקה, והקונקורנציה של ספרים חיים. אותו{ data, meta, pagination } מעטפה, אימות ודפדוף עם סמן כמו שאר ה-API.

גילוי שוק. הלך במשפך: /v3/sports/leagues → /v3/sports/markets?league=… → קח את ה tokens[] (כל אחד הוא תוצאת asset_id) → /v3/sports/books/{asset_id}/latest לספר החי.

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

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

שווקי ספורט ב-Polymarket ו-Kalshi. סנן עם ?league= (למשל nba, mlb, soccer); מדורגים בדפדוף כמו כל נקודת קצה של רשימה (?limit=, ?cursor=). כל שוק נושא את condition_id, market_slug, outcomes, ו tokens — עבור כל תוצאה asset_idשאתה מוסר לנקודת הקצה של הספר.

{ "data": [{
  "condition_id": "0xfb53…", "market_slug": "mls-nyc-laf-…-total-2pt5",
  "league": "soccer", "kind": "totals", "title": "New York City FC vs. Los Angeles FC",
  "outcomes": ["Over", "Under"],
  "tokens": ["45485059…", "38846626…"],   // one asset_id per outcome
  "game_start": "2026-11-05T00:30:00Z", "resolved": false
}], "pagination": { "next_cursor": "…", "has_more": true, "limit": 50 }, "meta": { … } }

ספר הזמנות מלא מוקלט חדש ביותר עבור תוצאה אחת — ה asset_id הוא אסימון מ-tokens[]. הסולם מגיע כמערכים מיושרים לאינדקס (bid_prices עם bid_sizes, ask_prices עם ask_sizes) במקום ה- [price, size] זוגות שהנתיבים לקריפטו מחזירים; מה משותף לכל מסלול ספר הזמנות רשימות כל הבדלים. לשימוש חי רגיש להשהייה, Quant ורמות גבוהות יותר יכולות להירשם לערוצי WebSocket של ספורט למטה.

צילומי סולם מלא היסטוריים לתוצאה. עמוד עם ?limit= ו ?cursor=; קשר זמן עם ?start_time= / ?end_time= (הקצר יותר ?from= / ?to= כינויים מתקבלים גם כן). הוסף ?interval=1m להחזיר את הצילום האחרון בכל דלי מיושר לאפוק; היחידות הנתמכות הן s, m, h, ו d, מ-שנייה אחת ועד יום אחד. השמט אותו, או השתמש ב-raw / tick, עבור כל צילום מצב שנתפס. עומק ספורט נלכד קדימה: ארכיון Polymarket מתחיל ב-14 באפריל 2026 וארכיון Kalshi מתחיל ב-12 ביוני 2026.

דגימות תקופתיות; אינו מבצע אינטרפולציה. דלי קיים בתגובה רק אם הספר נלכד בתוכו, כך שחלון של שעתיים ב ?interval=1m משתרע על 120 דליים אך מחזיר רק את הדקות שהכילו לכידה. עבור תוצאה שמצטטת לעיתים רחוקות — שוק שעדיין ימים עד תחילת המשחק — זה בדרך כלל עשר עד עשרים שורות, וזה הטייפ המלא לחלון במקום עמוד מקוצר. כל תגובה שהשתמשה ב ?interval= נושא את ה resolution חסום כך ששניים יהיו מובחנים:

{ "data": [ … ],
  "pagination": { "count": 13, "has_more": false, "limit": 500 },
  "resolution": {
    "interval_secs": 60,
    "buckets_in_range": 121,   // minutes the window spans
    "buckets_filled": 13,      // minutes that held a capture
    "complete": true           // false while a next_cursor is outstanding
  } }

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

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

משחקים והקשר שוק שסוכם

משחקים ותוצאות חיים לליגה (למשל nba, nfl, soccer/eng.1), כל אחד עם שוקי Polymarket ו-Kalshi המקושרים אליו.

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

רשימת השווקים המוטמעת היא תצוגה מקדימה של עד 1,000 רשומות. בדוק markets_returned ו markets_truncated, ואז עקוב markets_url והסמן שלה מההתחלה לאוסף המלא. קריאות נתונים שנכשלו מחזירות 503 CATALOGUE_UNAVAILABLE; שמור את הרשומות הקודמות שלך ונסה שוב במקום להתייחס לחיפוש לא זמין כאל תוצאה ריקה.

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

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

שחקנים, פרופס ופציעות

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

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

הזנת פציעות חיה לפי ליגה — שינויים במצב לפני המשחק שמשפיעים על השוק.

סיכויי ספר ספורט

קו כסף חי, מרווח, סך וקווי prop ברחבי ספרים, מנורמלים להשוואה עם מחיר השוק.

קטלוג ספרי הספורט הפעילים ורעננות המקור.

קווי ספורטבוק היסטוריים לארבע ליגות: nfl (nflverse, עונות 1999–2026) ו epl, la-liga, soccer (football-data.co.uk, 2000/01 ואילך). כל ליגה אחרת מחזירה 404 SPORTS_UNKNOWN_ROUTE לקרוא לארבעת אלה. בקשה צריכה לפחות מסנן אחד: NFL לוקח season, team, מ, או ל; כדורגל לוקח קוד עונה של football-data (לדוגמה 2324) ו/או team. בלעדיו תקבל 400 INVALID_PARAMETER אומר איזה.

אירועים שנשלחים מהשרת לשינוי קווי ספרי ספורט. שלח Accept: text/event-stream; אירועים עוברים כפי שהם מגיעים והחיבור נשאר פתוח. ספרי הזמנות ספורט משתמשים ב-WebSocket הראשי של DepthFeed למטה.

Webhook לפציעות

רשום מקבל HTTPS עם מסנני ליגה ומצב פציעה. סוד החתימה מוצג פעם אחת. המסירות כוללות X-DepthFeed-Event ו X-DepthFeed-Signature; אמת את חתימת HMAC-SHA256 על גוף הבקשה הגולמי המדויק לפני ניתוח JSON.

curl -X POST "https://api.depthfeed.com/v3/sports/webhooks" \
  -H "Authorization: Bearer df_your_key" -H "Content-Type: application/json" \
  -d '{"url":"https://example.com/depthfeed","leagues":["nba","nfl"],"statuses":["out","questionable"]}'

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

# discover a market, then pull its live book
curl "https://api.depthfeed.com/v3/sports/markets?league=mlb&limit=1" -H "Authorization: Bearer df_your_key"
# take tokens[0] from the response, then:
curl "https://api.depthfeed.com/v3/sports/books/<asset_id>/latest" -H "Authorization: Bearer df_your_key"

FIX 4.4 נתוני שוק על TLS

חבר מערכת נתוני שוק FIX קיימת לספרי הזמנות מנורמלים מ-Binance, Polymarket, Kalshi, Limitless וערוצי ספורט נתמכים. הפרופיל מספק תצלומי מצב ראשוניים, עדכוני רמות מחיר חדשים/משתנים/מוחקים, פעימות לב, מספרי רצף מתמשכים ושחזור מילוי פערים ואחריו תצלומי מצב חדשים. הוא צורך את אותו פיד כמו WebSocket.

REST נשאר ממשק לגילוי ולנתוני היסטוריה. פרופיל FIX זה מכסה נתוני שוק; הוא אינו מנתב הזמנות או מספק השמעת טיקים היסטורית. הוא אינו מוסיף כיסוי תפיסה עצמאי או הבטחת השהייה. חותמות זמן מקור וחותמות זמן שליחת שער שונות מקבלת הלקוח.

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

WebSocket שדוחף ספרי הזמנות ומחירים חיים כפי שהם משתנים. מטעני מסגרת הם ה- אותם אובייקטי JSON שהנקודות קצה של תמונת מצב REST מחזירות, כך שקוד שנכתב נגד REST מועבר ישירות. אמת בעת חיבור עם X-API-Key כותרת, Authorization: Bearer, או — לדפדפנים, שאינם יכולים להגדיר כותרות WebSocket — ?api_key=df_….

# wscat -c "wss://api.depthfeed.com/v3/stream?api_key=df_your_key"
> {"op":"subscribe","channels":["book:polymarket:btc:2510645","price:btc"]}
< {"op":"subscribed","channels":[…],"active":2}
< {"channel":"price:btc","data":{"coin":"btc","price":63560.1,…},"ts":1781300671083}
< {"channel":"book:polymarket:btc:2510645","data":{…same shape as REST snapshot…},"ts":…}

ערוצים

פעולות: subscribe · unsubscribe (כל אחד לוקח {"channels":[…]}, מוחל אטומית) ו ping → pong. עקבי * מקטע שוק (למשל. book:kalshi:btc:*) מנוי לזירה/מטבע שלם — רק תוכנית Desk. בעיות ברמת הפעלה (ערוץ שגוי, חריגה מהמנוי שלך) מוחזרות כ- {"op":"error","code":…} מסגרות ולעולם אל תנתק את החיבור.

ערוצי ספורט משתמשים במזהים מוחשיים ואינם תומכים בתווים כלליים. Quant, Research ו-Desk מאפשרים ספרי ספורט בו-זמניים אחד, שניים ושלושה בהתאמה. כל מסגרת ספורט כוללת את הסולם המלא, venue, asset_id, חותמות זמן החלפה/קבלה, full_ladder: true, וdelivery שדה שמציין את מקור כל מסגרת: polymarket_clob_ws,kalshi_orderbook_delta_ws, או scoretape_relay כאשר ריליי הספורט פעיל. ספרי הספורט של Kalshi מונעים על ידי websocket דלתא של ספר ההזמנות המאומת של Kalshi, עם הריליי כגיבוי, כך שתזמון המסגרות עוקב אחרי פעילות הבורסה ולא לפי מרווח קבוע. קרא רעננות מתאריכי התצפיות במקום להניח קצב רענון.

> {"op":"subscribe","channels":[
    "book:sports:polymarket:<token_id>",
    "book:sports:kalshi:<market_ticker>"
  ]}
< {"op":"subscribed","channels":[…],"active":2}

מגבלות לפי תוכנית

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

מסגרות שגיאת פעולות

אלה מגיעים כ {"op":"error","code":…,"message":…} ושומרים על החיבור פתוח. אלו קודי מסגרת, לא סטטוסים HTTP.

קודי סגירה וחיבור מחדש

השרת שולח פעימות לב עם פינגי פרוטוקול כל 25 שניות. פריסות וכישלונות מנתקים חיבורים במכוון — התייחס התנתק → התחבר מחדש עם חזרה אקספוננציאלית (250ms הכפלה עד ~5s) ושלח מחדש את המנויים שלך כחלק ממחזור החיים הרגיל, לא כדרך שגיאה.

טריות ועיכוב

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

מדוד קבלה עצמאית של לקוח עם שעון מסונכרן, שמור מקור חותמת זמן, ודווח כל venue, אזור, מטען וחלון מדידה בנפרד. היסטוריdeploy/stream_freshness.py תצפיות מתארות את הריצות האלה, ולא הבטחת השהייה נוכחית לכל מנוי. FIX ארגוני משתמש באותו פיד בסיסי; חותמות הזמן של השליחה והמקור שלו מתוארות בפרופיל FIX למעלה.

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

ביקורת ביצוע ספר הבא

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

ציונים הם מכניים: העומק שנותר משמעותו לפחות 95% מהגודל הציבורי הוצג בתוך 1¢ ממחיר הסוחר; המחיר זז משמעותו לפחות 95% נשאר אך בהפרש מעל 1¢; גודל לא זמין משמעותו שפחות מ-95% מהגודל הציבורי הוצג.

עותק נייר קדימה

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

קריאת HTTPS אופציונלית מקבלת כל מילוי מועתק מוצלח. סוד החתימה שלה מוצג פעם אחת. אמת HMAC-SHA256(timestamp.body) נגד x-depthfeed-signature; חותמת הזמן נשלחת ב x-depthfeed-timestamp. כתובות מקומיות, רשת פרטית, עם אישורים, שאינן HTTPS, ויעדים עם הפניות נדחות.

מגבלות פרשנות

• כתובת ציבורית עשויה להיות רק ארנק אחד בתיק של סוחר ואינה מוכיחה זהות או בעלות.
• חותמות זמן של פעילות ציבורית אינן חותמות זמן של הזמנות פרטיות. הביקורת מודדת מה ש-DepthFeed הבחין לאחר הפרסום, לא את ההשהיה המקורית של הסוחר.
• רק עסקאות בכיסוי Polymarket המוקלט של DepthFeed ניתנות להתאמה. שווקים לא נתמכים או לא מתועדים מוצגים ללא ביקורת.
• ההפעלה מחדש צורכת את הגודל המוצג מתמטית; היא אינה יכולה לדמות נזילות נסתרת, עדיפות בתור, מרוצי ביטול, עמלות או השפעת שוק של הזמנה ממשית העוקבת.
• דירוג טבלה, רווח והפסד, מיקומים ופעילות מגיעים משירותי הנתונים הציבוריים של Polymarket ועשויים להיות מאוחרים, מתוקנים, לא שלמים או זמנית לא זמינים.
• Wallet Intelligence והמראה הניירית שלו הם כלי מחקר — לא מסחר העתק חי, ייעוץ השקעות, המלצה או הבטחת ביצוע.

מדריכי מחקר ארנק

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

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

בנה והרץ

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

הנחות ביצוע

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

המשך במסחר נייר

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

מסחר מדומה מריץ אסטרטגיות קדימה על חי שווקים עם כסף וירטואלי. מילויים, סימונים ופשרות מתומחרים כולם מספרי ההזמנות החיים של DepthFeed — קניות במחיר הבקשה, מכירות במחיר ההצעה, עמדות מתפשרות ל-$0/$1 אוטומטית כשהשוק מתפענח. לכל אסטרטגיה יש עקומת הון משלה, תצוגת עמדות ורשומת מסחר מלאה.

שלוש דרכים לסחור

Webhook אות

האסימון (מוצג פעם אחת ביצירה/סיבוב) הוא האימות. מילויים תמיד מתומחרים מהספר החי בזמן האות — מטען לעולם לא יכול לקבוע את המחיר שלו. שווקים מזוהים על ידי venue + market: טיקר של Kalshi, או מזהה אסימון CLOB של Polymarket. ניתן לסחור כל שוק בפלטפורמה, לא רק אלה ש-DepthFeed רושמת — אם אין לנו את זה מקומית, המילוי מתומחר מקריאה חיה של ספר ההזמנות של הזירה עצמה.

curl -X POST 'https://api.depthfeed.com/paper/hook/pt_your_token' \
  -H 'content-type: application/json' \
  -d '{
    "action": "buy",
    "venue": "polymarket",
    "market": "REPLACE_WITH_CLOB_TOKEN_ID",
    "side": "yes",
    "usd": 100,
    "client_id": "sig-0042"
  }'

{ "data": { "filled": true, "action": "buy", "price": 0.62,
            "shares": 161.29, "cost_cents": 10000, "cash_cents": 990000,
            "position_id": "…" } }

מפסק מעגל

לכל אסטרטגיה יש trailing עצירת מקסימום ירידה (ברירת מחדל 60%, ניתן לעריכה; הגדר ל-0 כדי להשבית). אם ההון החי יורד מתחת לסימן המים הגבוה שלו כל כך, האסטרטגיה מתבטלת אוטומטית במחירים הנוכחיים ו הופסק — עצירה קשיחה נגד אסטרטגיה שמסחרת בעצמה לכיוון אפס. המשך בכל עת; המשך מאפס את סימן המים הגבוה להון הנוכחי שלך.

מגבלות

אסטרטגיות מקבילות לפי תוכנית: Explorer 1 · Quant 5 · Research 15 · Desk 40. עד 100 פוזיציות פתוחות לכל אסטרטגיה; יתרת התחלה $100–$1,000,000 (ברירת מחדל $10,000). סימוני מחיר מתעדכנים בקצב של כ-90 שניות — זהו עוקב בדיקות קדימה, לא פלטפורמת ביצוע.

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

• ה- { data, pagination, meta } מעטפה ו meta.request_id.
• מערך מפתחות cursor דפדוף ו limit.
• החלון, כ start_time/end_time או מ/ל.
• interval לספר אחד לכל דלי, ו fill=ffill לרשת צפופה.
• filled, as_of_ts, ו as_of_ts_ms בשורות מלאות.
• ה- resolution חסום על כל תגובה שהשתמשה interval.
• חלון היסטוריית התוכנית, ו error.code אנום.

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

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

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

כל 7 הנכסים (btc · eth · sol · xrp · doge · bnb · hype) בכל זירת מסחר שמפרסמת אותם.

חותמות זמן הן epoch-millis. exch_ts_ms = זמן בורסה, recv_ts_ms = זמן קבלתנו (ההבדל הוא זמן לכידה). להלן העמודות המאוחסנות. נתיבי הקריפטו והזירה מצמדים את ארבע מערכי המחיר/גודל ל bids / asks זוגות לפני החזרתם; הנתיבים לספורט מעבירים אותם כארבע מערכים. כל השאר מגיע אליך תחת השם שבו הם מאוחסנים.

polymarket_book — תמונות מצב מלאות של ספר הזמנות

asset_id, condition_id, slug, base_asset, market_type, exch_ts_ms, recv_ts_ms, hash, bid_prices[], bid_sizes[], ask_prices[], ask_sizes[]

polymarket_changes — דלתות לשחזור בין תמונות מצב

asset_id, condition_id, exch_ts_ms, recv_ts_ms, side, price, size

polymarket_markets — שורה אחת לכל טוקן

asset_id, market_id, event_id, condition_id, slug, outcome, base_asset, market_type, clob_token_up, clob_token_down, resolution_source, start_time, end_time, first_seen_ms

polymarket_reference — הסדר

slug, base_asset, market_type, start_ms, end_ms, price_to_beat, final_price, winner, final_volume, final_liquidity, resolved_at, captured_ms

binance_book — ספר ברמה 20 (ספוט וחוזים עתידיים)

venue, symbol, exch_ts_ms, recv_ts_ms, bid_prices[], bid_sizes[], ask_prices[], ask_sizes[]

binance_trades_1s — 1s OHLCV

venue, symbol, second_ms, open, high, low, close, volume, buy_volume, sell_volume, trades, recv_ts_ms

מחירים — סדרת מחירי בסיס מאוחדת

asset, source (binance|chainlink), venue, exch_ts_ms, price

kalshi_book / kalshi_markets

kalshi_book: ticker, series, base_asset, market_type, recv_ts_ms, yes_prices[], yes_sizes[], no_prices[], no_sizes[]

kalshi_markets: ticker, event_ticker, series, base_asset, market_type, title, status, strike, open_time, close_time, first_seen_ms

limitless_book / limitless_markets

limitless_book: slug, condition_id, base_asset, market_type, recv_ts_ms, midpoint, bid_prices[], bid_sizes[], ask_prices[], ask_sizes[]

limitless_markets: slug, condition_id, base_asset, market_type, title, status, expiration_ms, first_seen_ms

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

רצפות ארכיון עומק מלא של Polymarket (UTC)

רצפה היא היום הראשון שבו נרשם סולם, שאינו היום הראשון של סדרה רציפה. ארכיון Polymarket מכיל אין דבר לפני 2026-01-03, וינואר הוא חמישה ימים מפוזרים (2026-01-03 עד 01-06, ו-01-24). כיסוי יומי רציף מתחיל 2026-02-12. בדיקה לאחור שדורשת סדרה רציפה צריכה להתחיל שם.

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

רצפות ארכיון Kalshi (UTC)

רצפות Kalshi הן נפרד מאלו של Polymarket למעלה והם מאוחרים יותר. סולם Kalshi המתועד המוקדם ביותר של כל סדרה הוא 2026-01-08. לסדרת הקריפטו של 15 דקות:

סדרות Kalshi שעתיות, יומיות ושבועיות נושאות רצפות משלהן לכל סדרה, ו-BTC, ETH, XRP ו-DOGE מתחילות ב-2026-01-08 גם שם. במקום לפרסם רצפה לכל סדרה, התייחסו לגילוי כסמכותי: /v3/kalshi/markets?series=KXBTC15M&start_time=…&end_time=… רשימות בדיוק את הטיקרים שעומקם ניתן לשליפה בטווח זה, ומזהי טיקר של Kalshi מוגדרים על ידי המקום, לכן יש לגלות אותם במקום לבנותם מתאריכי זמן UTC.

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

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

מכירות נתונים המוניים כל ימי UTC של הארכיון כקבצי Parquet חתומים ב-zstd, קובץ אחד לכל טבלה ליום, מסופק מאחסון אובייקטים באמצעות URL חתום קצר מועד. הוא יושב לצד REST API, לא לפניו: ה-API עדיין משרת את החלון החם ואת מסלולי ההיסטוריה, וקבצים בכמות גדולה מסירים מהם את עבודת "הליכה לאורך כל הארכיון". מראש משולם, מתומחר לפי GiB, ומוגבל ברישיון נתונים שאתה מקבל פעם אחת בלוח המחוונים.

מוצרים

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

מחירונים

חתימה

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

רישיון

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

נתיבים

הטבלאות הניתנות למכירה עם שיעורן.

curl https://api.depthfeed.com/v3/data/products   -H "Authorization: Bearer df_your_key_here"

האם חשבון זה קיבל את הרישיון, ואיזו גרסה.

curl https://api.depthfeed.com/v3/data/licence   -H "Authorization: Bearer df_your_key_here"

רשום את קבלת הגרסה המודפסת בדף הרישיון.

curl -X POST https://api.depthfeed.com/v3/data/licence/accept   -H "Authorization: Bearer df_your_key_here"   -H "Content-Type: application/json"   -d '{"version":"2026-10-06"}'

יתרת מראש כ credits ו usd. תוספות נעשות מלוח הבקרה.

curl https://api.depthfeed.com/v3/data/balance   -H "Authorization: Bearer df_your_key_here"

ימים חתומים למוצר אחד בין מ ו ל (תאריכי UTC, כולל), כל אחד עם bytes, rows, etag, version ו sealed_at. דפדוף עם סמן כמו בכל רשימה.

curl "https://api.depthfeed.com/v3/data/catalogue?product=kalshi-ticks&from=2026-09-01&to=2026-09-30&limit=100"   -H "Authorization: Bearer df_your_key_here"

תמחור בחירה. מחזיר את הציטוט id, total_bytes, price_credits ו expires_at (15 דקות). הצעת מחיר מחזיקה את המחיר, לא כסף: אינך צריך קרדיטים מראש כדי לבקש אותה. הצעת מחיר חדשה מבטלת הצעות פתוחות קודמות אלא אם יש להן תשלום בכרטיס חי. שלם ידנית בכרטיס באמצעות נקודת התשלום למטה, או הסדר מחשבון הקרדיטים שלך. כל הצעה והזמנה נושאים non_refundable: true.

curl -X POST https://api.depthfeed.com/v3/data/quotes   -H "Authorization: Bearer df_your_key_here"   -H "Content-Type: application/json"   -d '{"items":[{"product":"kalshi-ticks","from":"2026-09-01","to":"2026-09-07"}]}'

קנה דרך ה-API ושלם ידנית. שלח את UUID של הציטוט לנקודת הקצה הזו ופתח את ה-payment_url (גם מוחזר כ url) בדפדפן. זו נקודת תשלום בכרטיס המארחת על ידי Stripe בדיוק להצעת המחיר הזו, לא חיוב מיידי. חזרה על בקשה זו בזמן שהתשלום חי מחזירה את אותו הקישור עם reused: true. השתמש ב expires_at.

curl -X POST https://api.depthfeed.com/v3/data/orders/checkout   -H "Authorization: Bearer df_your_key_here"   -H "Content-Type: application/json"   -d '{"quote_id":"11111111-1111-1111-1111-111111111111"}'

{ "data": {
  "quote_id": "11111111-1111-1111-1111-111111111111",
  "payment_url": "https://checkout.stripe.com/c/pay/...",
  "payment_status": "awaiting_payment",
  "price_usd": 12.34,
  "expires_at": "2026-10-19T01:32:00Z",
  "reused": false
} }

לאחר תשלום ידני, webhook מאומת של Stripe יוצר את ההזמנה בתשלום. סקרGET /v3/data/orders עם חזרה מוגבלת והתאמה quote_id; דף ההחזרה של הדפדפן אינו מוכיח תשלום. ברגע שהזמנה היא paid, בקש את קישורי ההורדה שלו. דוא"ל הורדה נשלח גם לכתובת האימייל של החשבון. תשלום לא משולם או שפג תוקפו לא יוצר הזמנה בתשלום. תשלום בקרדיטים על אותה הצעת מחיר נחסם בזמן שתשלום בכרטיס חי.

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

curl -X POST https://api.depthfeed.com/v3/data/orders   -H "Authorization: Bearer df_your_key_here"   -H "Content-Type: application/json"   -d '{"quote_id":"q_01J…"}'

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

curl https://api.depthfeed.com/v3/data/orders   -H "Authorization: Bearer df_your_key_here"

הנפק כתובות URL חתומות לכל פריט בהזמנה. כל URL תקף לשעה אחת ומהווה אסימון נושא עבור הקובץ, לכן שמור אותו במערכות שלך. קרא שוב מתי שצריך סט חדש, בחינם, למשך 30 ימים. פריט שיום שלו נסגר שוב חוזר עם status: "reissued_new_version" ו-URL חדש. יום ללא קובץ נוכחי הוא unavailable.

curl -X POST https://api.depthfeed.com/v3/data/orders/ord_01J…/links   -H "Authorization: Bearer df_your_key_here"

{ "data": { "items": [
  { "item_id": "…", "product": "kalshi-ticks", "day": "2026-09-01", "bytes": 3650722201,
    "url": "https://<account>.r2.cloudflarestorage.com/…?X-Amz-Expires=3600&…",
    "expires_at": "2026-10-06T13:00:00Z", "status": "ready" }
] } }

הלך בהיסטוריית עומק מלאה של שוק (Python)

import requests

BASE = "https://api.depthfeed.com/v3"
H = {"Authorization": "Bearer df_your_key"}

# 1. find a market
m = requests.get(f"{BASE}/btc/markets?type=15m&limit=1", headers=H).json()["data"][0]
mid = m["market_id"]

# 2. page through its order-book snapshots
cursor, rows = None, []
while True:
    q = f"{BASE}/btc/markets/{mid}/snapshots?include_orderbook=true&limit=1000"
    if cursor: q += f"&cursor={cursor}"
    page = requests.get(q, headers=H).json()
    rows += page["data"]
    if not page["pagination"]["has_more"]: break
    cursor = page["pagination"]["next_cursor"]

print(len(rows), "snapshots")

עומק חוצה פלטפורמות עבור BTC למעלה/מטה (JavaScript)

const h = { Authorization: "Bearer df_your_key" };

// One call → the full BTC 15m book on all three venues at once.
// (No stitching: the screener is the cross-venue entry point.)
const res = await fetch("https://api.depthfeed.com/v3/screener/btc/15m", { headers: h }).then(r => r.json());
const { books } = res.data;        // books.polymarket / books.kalshi / books.limitless

DepthFeed בנוי להיות מונע על ידי סוכנים: JSON פשוט מעל HTTPS, מפתח Bearer אחד, קודי שגיאה יציבים, ואין צורך ב-SDK. סיכום מוצר קריא למכונה נמצא ב /llms.txt.

כלי בסגנון קריאת פונקציה / MCP

עטוף כל נקודת קצה ככלי — ה-API מתאר את עצמו די כדי שהגדרה גנרית אחת תכסה רוב זרמי העבודה:

{
  "name": "depthfeed_get",
  "description": "Query DepthFeed prediction-market order-book data. Paths: /v3/{coin}/markets, /v3/{coin}/markets/{id}/snapshots, /v3/kalshi/markets, /v3/kalshi/{ticker}/snapshots, /v3/kalshi/{ticker}/candles, /v3/limitless/{slug}/snapshots, /v3/{coin}/{spot|futures}/latest. Coins: btc eth sol xrp doge bnb hype.",
  "parameters": {
    "type": "object",
    "properties": { "path": { "type": "string", "description": "GET path under /v3, with query params" } },
    "required": ["path"]
  }
}

גוף הכלי הוא GET מאומת יחיד:

curl "https://api.depthfeed.com{path}" -H "Authorization: Bearer df_your_key"

נתונים חיים בסוכנים

ה- זרם WebSocket משתמש בשלוש פעולות JSON (subscribe / unsubscribe / ping) ומאמת עם ?api_key= כאשר לא ניתן להגדיר כותרות — פשוט להנעה מכל סביבת ריצה. המסגרות נושאות את אותם אובייקטי JSON כמו REST, כך שקוד הפירוש של הסוכן זהה להיסטוריה ולחי.

מה בשידור חי, הכי חדש ראשון:

• בונה אסטרטגיות. בדיקות חוזרות בהנחיית עוזר וקנבס אסטרטגיה חזותית משתמשים באותו מנוע ב /dashboard/backtest.
• ברי מחיר. /v3/bars מספק OHLCV למניות, ETFs וקריפטו בתוך חלון ההיסטוריה של התוכנית שלך.
• הורדות המוניות. ניתן לרכוש בנפרד קבצי Parquet יומיים שלמים לפי UTC בנוסף לגישה ל-API.
• שידור חי. /v3/stream WebSocket — ערוצי ספר הזמנות ומחירים בכל venue, תפיסה ומשלוח תלויי venue, מנויים מוגבלים לפי תוכנית.
• Limitless venue. שווקים, ספר הזמנות עדכני, ונתוני עומק היסטוריים — עם 5 דקות + 15 דקות שנתפסו בשידור חי דרך websocket של ספר ההזמנות.
• Kalshi מורחבת. 21 סדרות לכל 7 הנכסים (15-דקות, סף, וכיווני — שני האחרונים פועלים במקביל לפי שעה/יומי/שבועי); market_type חשוף וסינון.
• API מלא v3. שווקי Polymarket + צילומי מצב, Binance ספוט/חוזים עתידיים, אצווה, דפדוף באמצעות סמן, אכיפת היסטוריה לפי תוכנית, שימוש מדוד.
• HTTPS ציבורי. https://api.depthfeed.com דרך TLS.

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