Dữ liệu DepthFeed
Tham khảo API

DepthFeed là sổ lệnh lịch sử độ sâu cho thị trường dự đoán — ghi lại đầy đủ thang giá mua/bán ở cả hai phía cho Polymarket, Kalshi, và Limitless. Không chỉ giá giao dịch cuối cùng hoặc đỉnh sổ lệnh: mỗi quan sát lưu trữ bao gồm các mức nghỉ và kích thước. Đây là dữ liệu bạn cần để kiểm thử lại một lệnh khớp dựa trên thanh khoản thực sự có mặt.

Nó được cung cấp qua REST API có giới hạn — khám phá thị trường, metadata, và snapshot sổ lệnh mới nhất + lịch sử, phân trang theo bộ khóa với kiểm soát truy cập chung và tải công việc lịch sử riêng biệt. Lấy chính xác độ sâu mà chiến lược của bạn cần và phát lại trong hệ thống của bạn.

Phạm vi bao phủ sổ lệnh 3 sàn giao dịch, 7 tài sản (btc · eth · sol · xrp · doge · bnb · hype) và các thị trường crypto tăng/giảm định kỳ mà mỗi sàn vận hành (5m, 15m, 1h, 4h, 24h, tùy sàn).

Giá là nửa sau của sản phẩm. /v3/bars phục vụ thanh giá OHLCV cho Cổ phiếu và ETF niêm yết tại Mỹ, cặp giao dịch tiền điện tử spot và hợp đồng tương lai vĩnh viễn trên mọi gói, với độ phân giải cơ sở một phút. Chúng chia sẻ đồng hồ, sơ đồ và cửa sổ lịch sử gói với các sổ lệnh ở trên, để một chiến lược có thể đọc cổ phiếu và hành động trên hợp đồng mà không cần đối chiếu dấu thời gian của hai nhà cung cấp.

Thể thao có trên mọi gói — toàn bộ bề mặt REST: sổ lệnh Polymarket và Kalshi, tỷ lệ cược sportsbook, điểm số và chấn thương trên các giải lớn. Gói trả phí thêm sổ lệnh trực tiếp độ trễ thấp qua WebSocket, một sổ lệnh đồng thời trên Quant và ba trên Desk. Chuyển đến Điểm cuối thể thao.

Mới bắt đầu đánh giá nguồn dữ liệu? The hướng dẫn người mua bao gồm năm tiêu chí quyết định liệu dữ liệu thị trường dự đoán có thực sự có thể kiểm thử lại hay không, và cách DepthFeed đáp ứng từng tiêu chí.

Sử dụng trang này làm hợp đồng vận hành khi LLM hoặc tác nhân trả lời câu hỏi về DepthFeed hoặc viết mã tích hợp. Ưu tiên phản hồi API được tài liệu hóa hơn giả định từ nhãn thị trường, ví dụ hoặc mô tả bên thứ ba.

Quy tắc chuẩn

1. Sử dụng https://depthfeed.com/docs như nguồn sự thật cho tên điểm cuối, trường dữ liệu, giới hạn và rào cản kế hoạch.
2. Chọn điểm cuối phù hợp với công việc: /v3/demo cho ví dụ không có khóa, /v3/markets cho khám phá, /v3/snapshots cho sổ lệnh lịch sử, /v3/stream cho sổ lệnh trực tiếp, /v3/sports/markets cho ánh xạ thể thao, và /v3/whoami cho giới hạn tài khoản.
3. Không suy luận sự tương đương đa sàn từ kind, nhãn, thứ tự mảng, hoặc cross_venue_key. Xác nhận contract_mapping.status=matched và điều khoản thanh toán trước khi xử lý một cross_venue_market_key như tương đương.
4. Giữ nguyên null, dấu thời gian, định danh venue và siêu dữ liệu một phần. HTTP 200 và tổng số không chứng minh phản hồi là đầy đủ.
5. Theo con trỏ mờ cho đến khi has_more là sai, giữ bộ lọc cố định xuyên suốt duyệt trang.
6. Để sửa lỗi, truy vấn updated_since, cập nhật theo danh tính thị trường hoặc điều kiện ổn định, giữ các thu hồi null, bao gồm thị trường đã giải quyết, và chồng chéo chỉ sau khi duyệt thành công.
7. Để kiểm tra lại, sử dụng độ sâu đặt mua/bán đầy đủ và kích thước đặt giữ. Không mô tả dữ liệu giá trung bình hoặc giá cuối cùng như các giao dịch có thể thực hiện.
8. Nêu rõ xác thực trạng thái, kế hoạch, cửa sổ lịch sử, giới hạn tốc độ và giả định về sàn giao dịch. Nếu tài liệu không xác nhận một sự thật, hãy ghi nhãn là chưa được xác nhận.

Hợp đồng trả lời

Các câu trả lời do mô hình tạo ra nên nêu rõ điểm cuối và mỏ neo tài liệu chính xác, hiển thị yêu cầu tối thiểu, giải thích các trường phản hồi được sử dụng, phân biệt ID gốc của venue với các khóa chuẩn, và tách biệt các sự kiện đã đo, phạm vi hiện tại, suy luận và những điều chưa biết. Không bao giờ khẳng định mối liên hệ giữa DepthFeed và một venue.

1. Tạo tài khoản miễn phí và tạo khóa API từ bảng điều khiển. Khóa trông như df_… và được hiển thị một lần.

2. Thực hiện cuộc gọi xác thực đầu tiên của bạn:

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

3. Phản hồi là một phong bì JSON. Trích đoạn này hiển thị tài khoản Quant; giới hạn của bạn phụ thuộc vào gói:

{
  "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. Lấy các thị trường BTC lên/xuống mới nhất, sau đó độ sâu sổ lệnh cho một trong số đó — xem Thị trường và Ảnh chụp nhanh.

Các endpoint dữ liệu xác thực yêu cầu khóa API. Các tuyến công khai bao gồm /v3/health, /v3/overview và /v3/demo. Chấp nhận cả hai cách — cả hai sơ đồ đều được chấp nhận:

# 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"

Khóa được tạo cho mỗi tài khoản từ bảng điều khiển và mang gói giới hạn tốc độ, cửa sổ lịch sử và truy cập tài sản/sàn. Khóa được lưu trữ Băm SHA-256 khi lưu trữ — giá trị thô được hiển thị chính xác một lần khi tạo. Thu hồi khóa trong bảng điều khiển có hiệu lực ngay lập tức. Hạn mức là mỗi người dùng, không phải mỗi khóa — các khóa bổ sung không nhân giới hạn của bạn.

Tất cả các điểm cuối hoạt động dưới một đường dẫn cơ sở được phiên bản duy nhất:

https://api.depthfeed.com/v3

Yêu cầu TLS (Let's Encrypt, HTTP/2). Phiên bản API hiện tại là v3, xây dựng để đạt chuẩn PolyBackTest (cùng phong bì, phân trang con trỏ và mã lỗi enum) trên dữ liệu tập hợp của chúng tôi (3 sàn, 7 tài sản). Cũ v1/v2 không phục vụ các namespace.

Mọi phản hồi thành công có cùng cấu trúc:

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

Lỗi có cùng cấu trúc, với trạng thái HTTP được đặt theo mã:

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

Mọi phản hồi — thành công hay lỗi — đều mang meta.request_id, cũng trả về dưới dạng X-Request-Id tiêu đề. Trích dẫn nó trong yêu cầu hỗ trợ.

Chuyển nhánh trên error.code — nó ổn định. Trạng thái HTTP được ngụ ý bởi mã.

403 HISTORY_LIMIT_EXCEEDED mang details.max_history_days và details.oldest_allowed. 429 cũng đặt Retry-After và X-RateLimit-* tiêu đề.

Giới hạn là một xô token theo người dùng với hai cửa sổ: mỗi giây bùng nổ và một mỗi phút duy trì giới hạn. Vượt quá sẽ trả về 429 với mã khớp và một Retry-After của 1 giây.

Explorer là một yêu cầu mỗi giây, không có giới hạn riêng cho mỗi phút. Đây là tốc độ, không phải hạn mức bùng phát: một vòng lặp chạy nhanh nhất có thể sẽ dành phần lớn yêu cầu của nó cho 429. Đọc X-RateLimit-Remaining, hoặc đơn giản ngủ một giây giữa các lần gọi.

Giá trị rps/rpm quảng cáo là giới hạn truy cập REST chung, không phải tỷ lệ phân phối kho lưu trữ. Snapshot lịch sử, các lô chứa đọc lịch sử và các tuyến nặng khác sử dụng kiểm soát đồng thời và phân phối cấp tài khoản riêng. Các kiểm soát này áp dụng độc lập với xô token chung và không thay đổi cửa sổ lịch sử của gói.

Explorer, Quant và Research hiện chấp nhận một yêu cầu lịch sử đang xử lý mỗi tài khoản. Desk chấp nhận 6 yêu cầu snapshot lịch sử song song mỗi tài khoản qua nhóm truy vấn Desk chuyên dụng. Giao nhau trả về 429 HISTORY_CONCURRENCY_LIMIT với Retry-After: 2; chỉ thử lại sau khi một yêu cầu đang hoạt động hoàn tất. Các giá trị rps/rpm chung không được sử dụng để suy ra khả năng song song trong lịch sử.

Một yêu cầu đọc lịch sử cũng có thể bị từ chối khi tài khoản của bạn vẫn nằm trong hạn mức của chính nó, vì nhóm truy vấn kho lưu trữ dùng chung bị bão hòa. Trường hợp đó trả về 429 HISTORY_POOL_BUSY với details.scope = "shared_pool" thay vì "account". Phân nhánh trên details.scope: trên account, giảm song song của bạn; trên shared_pool, giảm song song sẽ không giúp — thử lại với độ trễ tăng dần.

/v3/bars có giới hạn đồng thời riêng, độc lập với cả hai kiểm soát trên. Vượt quá sẽ bị từ chối ngay lập tức với 503 BARS_BUSY và details.retry_after tính bằng giây, thay vì xếp hàng — từ chối nhanh bạn có thể thử lại hữu ích hơn thành công chậm bạn không thể dự trù. Xử lý chính xác như 429: lùi lại và thử lại yêu cầu giống nhau. Các thanh cũng có hai giới hạn không phải là giới hạn tốc độ — kích thước lô (402 SYMBOL_LIMIT_EXCEEDED) và phạm vi mỗi yêu cầu (400 WINDOW_TOO_WIDE) — cả hai đều được sửa bằng cách chia nhỏ yêu cầu, không phải chờ đợi.

Xem Gói & quyền truy cập cho rps/rpm mỗi cấp.

Mẫu truy vấn lịch sử

Giữ không vượt quá số lượng lịch sử đồng thời đã xác nhận. Dùng giới hạn có biên start_time vàend_time, phân trang con trỏ, và limit=1000; bỏ qua include_count và yêu cầu bậc đầy đủ chỉ khi cần. Thêm interval khi chuỗi giảm mẫu là đủ. DepthFeed là sản phẩm truy vấn có giới hạn: tệp số lượng lớn, giao hàng kho lưu trữ ngoại tuyến, sao chép cơ sở dữ liệu và phản chiếu kho lưu trữ hệ thống không bao gồm.

Các điểm cuối danh sách sử dụng mã hóa mờ con trỏ bộ khóa — O(1) ở bất kỳ độ sâu nào. Bỏ qua ?cursor= từ trang trước pagination.next_cursor; dừng khi has_more là 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
}

Tham số truy vấn chung

từ/đến và start_time/end_time là cùng một cửa sổ. Cả hai cách viết đều hoạt động ở mọi nơi; nếu một yêu cầu nào đó mang cả hai, start_time/end_time thắng.

Dấu thời gian chấp nhận hoặc mili giây kể từ epoch (ví dụ 1780774485780) hoặc ISO-8601 (ví dụ, 2026-06-07T02:27:09Z). Mọi giá trị đến cơ sở dữ liệu đều được xác thực và an toàn khỏi tiêm nhiễm. Cửa sổ lịch sử gói được áp dụng trên mọi điểm cuối danh sách/snapshot: một start_time ngoài phạm vi cửa sổ 403; một cái bị bỏ qua sẽ bị giới hạn ở sàn giao dịch của cửa sổ.

Giảm mẫu với interval

Theo mặc định, các điểm cuối snapshot trả về mỗi thay đổi sổ lệnh đã ghi — độ phân giải sự kiện đầy đủ. Khi bạn chỉ cần mẫu định kỳ (ví dụ một sổ lệnh mỗi phút cho biểu đồ hoặc backtest thô), thêm ?interval= và máy chủ gộp mỗi nhóm thời gian thành một snapshot duy nhất: cái sổ lệnh gần nhất trong nhóm đó. Đây là dữ liệu ít hơn nhiều trên đường truyền so với việc lấy từng tick và lọc phía khách hàng.

# 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"

Chấp nhận một khoảng thời gian: một số giây trần, hoặc một giá trị có đơn vị — 30s, 1m, 5m, 15m, 1h, 4h, 1d — từ 1s đến 1d. Các nhóm được căn chỉnh với epoch, vì vậy 1m bám vào ranh giới phút đồng hồ tường. Phân trang con trỏ và include_count áp dụng cho các dòng giảm mẫu (total_count trở thành số lượng bucket). Bỏ qua nó, truyền raw, hoặc truyền 0 cho độ phân giải đầy đủ. Giá trị không nhận dạng trả về 400 INVALID_INTERVAL. Hoạt động trên mọi điểm cuối snapshot — Polymarket, Kalshi, Limitless, PredictFun, Binance và thể thao.

Chọn mẫu theo khoảng; không nội suy. Một thùng xuất hiện trong phản hồi chỉ khi có một sổ lệnh được ghi lại bên trong nó. Hai giờ tại ?interval=1m bao phủ 121 ranh giới phút nhưng chỉ trả về các phút có dữ liệu ghi nhận — thường là mười đến ba mươi trên thị trường không được báo giá tích cực. Đó là bản ghi đầy đủ cho cửa sổ, không phải trang bị cắt ngắn.

Lấp đầy khoảng trống với fill=ffill

Một sổ lệnh giữ trạng thái cho đến khi có thay đổi, nên một phút không ghi nhận không phải là mất dữ liệu — sổ lệnh phút trước vẫn là sổ lệnh. ?fill=ffill nói rõ: một hàng mỗi nhóm cho toàn bộ cửa sổ, với sổ lệnh cuối cùng được mang vào các nhóm không có dữ liệu ghi nhận. Đây là điều bạn muốn khi chuỗi phải căn chỉnh với đồng hồ cố định, thanh giá hoặc venue khác.

# 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 yêu cầu interval; tự nó trả về 400 INVALID_PARAMETER. Các giá trị được chấp nhận là ffill (cũng previous, prev, true, 1) và none (cũng false, 0, mặc định). Nó được hỗ trợ trên cùng các tuyến như interval. Danh sách, tick, nến và orderbook/latest các tuyến không có lưới để điền và bỏ qua tham số thay vì từ chối, nên khách gửi ở mọi nơi vẫn nhận được bình thường 200 từ họ.

Đồng hồ riêng của hàng thay đổi khi bạn bật fill bật. Với interval một mình dòng là một bản ghi thực, nên id và time/timestamp là thời điểm nó được ghi lại — 04:37:59.926 cho nhóm 04:37. Với fill=ffill mỗi hàng đại diện cho một bucket, bao gồm cả những cái được bắt, nên các trường đó trở thành ranh giới bucket (04:37:00.000) và thời điểm ghi lại chuyển sang as_of_ts. Không mất gì theo cả hai cách, nhưng biểu đồ vẽ từ cả hai sẽ bị lệch đến một khoảng thời gian trừ khi bạn đọc cùng một trường ở cả hai. Nếu bạn cần lưới và thời điểm ghi lại cùng nhau, hãy yêu cầu fill=ffill và đọc as_of_ts.

Đọc một hàng đã khớp

Phản hồi đã khớp thêm ba trường, và chỉ phản hồi đã khớp có chúng. Yêu cầu không có fill trả về chính xác hình dạng như trước đây.

Dấu thời gian nhóm và as_of_ts gần nhưng không bằng ngay cả trên một bản ghi, vì bản ghi nằm đâu đó trong nhóm thay vì trên ranh giới: 2026-09-02T00:50:00.000Z với as_of_ts của 2026-09-02T00:50:44.437Z là một phút thực sự có sổ lệnh thực sự.

Hàng đầu tiên của cửa sổ đã điền thường là hàng được chuyển tiếp. Lưới được khởi tạo với sổ lệnh mới nhất được ghi lại trước cửa sổ mở, vì vậy chuỗi bắt đầu từ trạng thái thực thay vì trống. Nó as_of_ts có thể cũ hơn vài giờ so với bucket đầu tiên, và đó là câu trả lời trung thực.

Khi cửa sổ mở trước khi thị trường mở, không có sổ lệnh trước để chuyển tiếp. Những thùng dẫn đầu đó trả về thang giá trống và as_of_ts: null — được tạo ra, không có gì để đặt vào chúng. Giới hạn start_time đến điểm bắt đầu riêng của thị trường để bỏ qua chúng.

The resolution khối

Mọi phản hồi đã dùng ?interval= mang một resolution chặn, để bạn có thể phân biệt bản ghi bắt dữ liệu thưa thớt với trang bị cắt ngắn mà không cần yêu cầu thứ hai.

"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 đếm các bản ghi bắt, không phải hàng, nên nó có nghĩa tương tự với fill bật như khi tắt. Đây là số để so sánh với buckets_in_range khi đánh giá mức độ thị trường được báo giá tốt. Với fill tắt, rows_returned và buckets_filled đồng ý. Khi bật, khoảng cách giữa chúng là bao nhiêu lưới được mang theo. Nếu buckets_filled thấp hơn nhiều buckets_in_range, yêu cầu khoảng thời gian thô hơn, hoặc bỏ qua interval và đọc mọi bản ghi.

Bốn gói cố định. Các plan trường trả về bởi /v3/whoami là giá trị thô ở cột bên phải.

Không có add-on Polymarket hoặc Kalshi. Cả hai venue thể thao sử dụng cùng một khóa, schema, giới hạn tốc độ và cửa sổ lịch sử; nâng cấp mua thêm lịch sử, thông lượng và đồng thời sổ lệnh trực tiếp.

Những gì Explorer truy cập được

Explorer là khóa thật trên dữ liệu thật, không phải sandbox: tất cả bảy coin, mọi venue, bảy ngày lịch sử, toàn bộ bề mặt REST thể thao, thanh giá và bộ lọc. Venue không bao giờ là thứ gói mua. Nâng cấp mua là cửa sổ lịch sử, thông lượng, đăng ký luồng và dữ liệu tick. Mỗi khóa trả về toàn bộ bậc thang; sổ lệnh duy nhất bị cắt trên API là bản demo không khóa, với tám mức mỗi bên.

Gia đình tuyến đường mà Explorer không thể truy cập là tick, chỉ dành cho Desk trên mọi sàn giao dịch và trả về 402 TICKS_NOT_IN_PLAN dưới đó. Giao diện demo ẩn danh — không cần khóa — bị giới hạn riêng cho mẫu BTC, và đó là thứ duy nhất trả lời 402 COIN_NOT_IN_PLAN.

Các cột rps/rpm chung mô tả việc chấp nhận yêu cầu, không phải quét kho lưu trữ đồng thời. Song song truy vấn lịch sử và kiểm soát giao hàng là riêng biệt. Đọc lịch sử Desk dùng nhóm truy vấn riêng chỉ dành cho Desk tách biệt khỏi lưu lượng truy vấn kế hoạch thường, không loại bỏ kiểm soát cấp tài khoản. Nhóm này chia sẻ giữa các tài khoản Desk và không phải hạ tầng sở hữu khách hàng hay độc quyền tài khoản.

Kiểm soát được thực thi phía máy chủ:

• Thị trường — mọi gói, bao gồm Explorer, đều tiếp cận mọi coin, mọi venue và toàn bộ sổ lệnh; thứ phân tầng là thông lượng, lịch sử và ticks, không phải quyền truy cập.
• Lịch sử — một cửa sổ ngoài gói của bạn → 403 HISTORY_LIMIT_EXCEEDED; nâng cấp sẽ mở rộng cửa sổ, không bao giờ danh sách thị trường.
• Thể thao — cái /v3/sports/* Bề mặt REST được bao gồm trong mọi gói; cùng cửa sổ lịch sử áp dụng cho cả hai sàn.
• Lịch sử — start_time ngoài cửa sổ của bạn → 403 HISTORY_LIMIT_EXCEEDED.
• Thanh giá — /v3/bars tuân theo cùng cửa sổ lịch sử như độ sâu, và thêm giới hạn ký hiệu mỗi yêu cầu (3 / 8 / 16 / 32), vượt quá sẽ trả về 402 SYMBOL_LIMIT_EXCEEDED.
• Phát trực tiếp — giới hạn áp dụng khi đăng ký trên /v3/stream; mọi gói đều truyền mọi sàn giao dịch — Explorer bị giới hạn ở một đăng ký đồng thời, các gói trả phí sẽ tăng số lượng.

Probe liveness, không xác thực. Trả về { status: "ok", service, time }.

Gói của bạn, giới hạn tốc độ, cửa sổ lịch sử hợp nhất, truy cập coin và truy cập thể thao — cách nhanh nhất để xác nhận khóa hoạt động.

Thị trường tăng/giảm Polymarket theo coin, kết nối với tham chiếu thanh toán (giá mở/đóng, người thắng, khối lượng). {coin} là một trong btc · eth · sol · xrp · doge · bnb · hype.

Bộ lọc: type (5m/15m/1h/4h/24h), resolved (true/false), cộng với các tham số thời gian + phân trang chung.

Một thị trường duy nhất theo id hoặc slug. Ví dụ về phản hồi (khóa giá mỗi xu là động, giống như tham chiếu):

{ "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": { … } }

The toàn bộ sàn Polymarket, không chỉ các thị trường crypto tăng/giảm. Các tuyến trên xử lý thị trường theo coin, nên chỉ có thể truy cập các thị trường có coin — bầu cử, địa chính trị, cổ phiếu và FX không có coin và không có URL ở đó. Đây liệt kê tất cả.

Bộ lọc: ?q= (tìm kiếm slug), ?type=event cho mọi thứ không phải là thang lên/xuống, cộng với ?coin=, ?event= và ?outcome=. Thị trường ở đây được khóa theo CLOB asset_id (token id); truyền nó đến /v3/polymarket/{asset_id}/snapshots cho lịch sử độ sâu hoặc /v3/polymarket/{asset_id}/ticks cho băng ghi. Thị trường phi tiền điện tử mang một base_asset — họ không có coin, và chúng tôi không tạo ra một cái.

Mỗi dòng mang category và tags. Thang lên/xuống là crypto; mọi thị trường khác lấy danh mục của nó từ các thẻ sự kiện của sàn giao dịch, với cách viết giống như Polymarket US (thể thao, crypto, politics, geopolitics, finance, macro, technology, science, climate, culture), với các slug thẻ thô trong tags và null nơi sàn không có nhãn. Lọc với ?category=politics,macro hoặc ?exclude_category=sports,crypto: phân tách bằng dấu phẩy, không phân biệt chữ hoa chữ thường, có thể kết hợp; một loại trừ giữ lại các thị trường không có nhãn. ?closed=true|false là cờ giao dịch của venue (thang đóng khi end_time đã qua). Đối với bản sao, ?updated_since= (ISO-8601, ngày hoặc epoch milliseconds) chỉ trả về các hàng có nội dung, nhãn hoặc trạng thái đóng thay đổi kể từ thời điểm đó; mỗi hàng có updated_at là dấu đó. resolved không phải bộ lọc trên tuyến này và được báo cáo dưới meta.ignored_params.

Lịch sử snapshot sổ lệnh cho bất kỳ thị trường Polymarket nào — thể thao, chính trị, tin tức và crypto — giới hạn bởi cửa sổ lịch sử của kế hoạch bạn. Cùng định dạng và phân trang như các tuyến snapshot theo đồng coin.

Băng ghi toàn venue cho cùng asset_id khóa.

Chuỗi thời gian độ sâu sổ lệnh cho một thị trường, với giá coin cơ sở được đóng dấu trên mỗi snapshot.

Thêm ?include_orderbook=true để lấy toàn bộ thang giá (mặc định bỏ qua để giảm tải). Có phân trang con trỏ theo cửa sổ thời gian. Thêm ?interval=1m (hoặc 5m, 1h, …) để giảm mẫu xuống còn một sổ lệnh mỗi nhóm thay vì chuỗi lưu trữ thô — xem Phân trang & bộ lọc. Phản hồi danh sách là một mảng với một pagination chặn:

{ "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": { … } }

Snapshot đơn gần nhất với dấu thời gian (trong ±2 giây). {timestamp} là ms-epoch hoặc ISO-8601. Không giống endpoint danh sách, data là một đối tượng đơn (cùng hình dạng hàng) với không pagination khối; không khớp trong vòng ±2 giây sẽ trả về 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": { … } }

Các cấp độ là [price, size]. price_up là điểm giữa giá mua/bán tốt nhất; price_down = 1 − price_up. Cái orderbook_down bên được suy ra là bù nhị phân của sổ lệnh lên (down = 1 − up, kích thước được giữ nguyên). Giá coin là tick gần nhất trước đó qua phép nối ASOF — chính xác cho 1h/4h/24h, proxy Binance có nhãn cho 5m/15m.

Mỗi dòng là một sổ lệnh hoàn chỉnh theo dấu thời gian của nó, không phải delta so với hàng trước đó, vì vậy bạn không bao giờ phải xây dựng lại trạng thái từ các thay đổi. Đối với luồng thay đổi, dùng tick.

Các tuyến snapshot venue khác

Cùng một hợp đồng — cửa sổ, con trỏ, interval, fill, cửa sổ lịch sử gói — được phục vụ bởi một tuyến mỗi sàn. Chúng khác nhau ở định danh nhận và cách trình bày hai phía của thị trường nhị phân, vì chính các sàn cũng vậy.

Lộ trình Polymarket tiếp cận toàn bộ sàn giao dịch, không chỉ các thang giá crypto — bầu cử, thể thao và mọi thứ khác Polymarket liệt kê. Lộ trình theo coin là góc nhìn crypto up/down với giá cơ sở được nối vào.

Băng ghi thô: mỗi thay đổi sổ lệnh cá nhân, không phải chuỗi snapshot mẫu. Ở đâu ảnh chụp nhanh cho bạn sổ lệnh tại các thời điểm, ticks cho bạn mọi thay đổi giữa chúng — điều mà quy trình tạo lập thị trường hoặc nghiên cứu thực thi cần để hỏi sổ lệnh ở thời điểm ngay trước khi khớp lệnh, hoặc mức giá tồn tại bao lâu trước khi bị lấy.

Chỉ dành cho doanh nghiệp. Các kế hoạch khác nhận được 402 TICKS_NOT_IN_PLAN.

Polymarket, lấy từ luồng delta CLOB. Cả hai token kết quả được trả về mặc định và được gắn nhãn outcome; thu hẹp với ?outcome=up hoặc ?outcome=down.

Lịch sử: băng ghi liên tục từ 2026-06-25 (đã kiểm tra 2026-09-02) và tiếp tục tích lũy, vì vậy cửa sổ đáng tin cậy tăng lên một ngày mỗi ngày. Các ngày trước đó tồn tại trong kho lưu trữ nhưng không liên tục — 61 ngày bị thiếu giữa 2026-04-14 và chuỗi liên tục — vì vậy một backtest cần chuỗi không gián đoạn nên bắt đầu không sớm hơn 2026-06-25.

Phạm vi: thị trường tăng/giảm trên 5m, 15m và 24h cửa sổ, trên tất cả bảy tài sản. Các 1h và 4h gia đình tăng/giảm là không hiện có trong băng ghi tick — sử dụng ảnh chụp nhanh cho những cái đó.

{ "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": { … } }

Mới — ghi nhận tick Kalshi bắt đầu 2026-08-07. Không có lịch sử tick Kalshi trước ngày đó; băng ghi tích lũy tiến về phía trước từ đó. Kalshi ảnh chụp nhanh vẫn có sẵn trong toàn bộ cửa sổ lịch sử.

Phạm vi là tập con lăn, không phải mọi thị trường Kalshi: bảy tài sản tiền điện tử, ưu tiên theo ngày hết hạn gần nhất, với số lượng thị trường giới hạn được ghi đồng thời. Liên hệ nếu bạn cần chuỗi cụ thể được bao phủ.

Nguồn từ xác thực orderbook_delta WebSocket. kind là snapshot cho các hàng neo một sổ lệnh (để bất kỳ cửa sổ nào bạn yêu cầu bắt đầu từ trạng thái đầy đủ) hoặc delta cho một sự thay đổi. delta là thay đổi kích thước có dấu và size là kích thước tồn tại tại giá đó sau nó. seq là số thứ tự riêng của Kalshi cho phiên ghi — tăng chính xác một đơn vị trong phiên, nên bạn có thể xác minh đoạn băng ghi là đầy đủ thay vì chỉ tin lời chúng tôi. Một chuỗi snapshot hàng đánh dấu phiên mới, nơi nó khởi động lại. Thu hẹp về một bên với ?side=yes hoặc ?side=no.

Tái tạo một sổ lệnh: xem mỗi snapshot chạy như một thiết lập lại cứng của sổ lệnh thị trường đó, sau đó áp dụng delta hàng trong seq thứ tự trong phiên. Sắp xếp theo seq, không phải bởi time: dấu thời gian của sàn giao dịch không đơn điệu trên các cấp độ trong vòng một mili giây, trong khi seq là. Bất kỳ seq bước khác +1 bên trong phiên là khoảng trống trên băng ghi cho đoạn đó; việc ghi lại tự động kết nối lại và chụp lại khi phát hiện khoảng trống, vì vậy tiếp theo snapshot chạy là điểm mà sổ lệnh lại hoàn chỉnh.

{ "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": { … } }

Trang chứa tối đa 10000 hàng (mặc định 1000) và được phân trang con trỏ như mọi điểm cuối danh sách khác. Nhiều tick thường chia sẻ một mili giây, vì vậy con trỏ mang vị trí trong một dấu thời gian — phân trang thị trường bận không bao giờ chia hoặc bỏ các dòng cùng thời điểm ranh giới.start_time/end_time và cửa sổ lịch sử gói của bạn áp dụng như thường lệ.

Sổ lệnh tài sản cơ sở và băng ghi giao dịch từ Binance. {venue} là spot hoặc futures. Sổ lệnh có 20 cấp mỗi bên.

Lịch sử sổ lệnh mới nhất / sổ lệnh phân trang. Mỗi snapshot: price (giữa), bids, asks, timestamp.

1-giây nến OHLCV với phân tách mua/bán mạnh mẽ — chính xác, 1:1 với tham chiếu:

{ "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": { … } }

Thanh giá OHLCV cho cổ phiếu và ETF niêm yết tại Mỹ, các cặp spot Binance và hợp đồng tương lai vĩnh viễn. Một phút là độ phân giải nhỏ nhất; các khung lớn hơn được tổng hợp từ nó.

symbols là danh sách phân cách bằng dấu phẩy. timeframe là một trong 1Min, 5Min, 15Min, 1Hour hoặc 1Day (mặc định 1Min). start_time, end_time, limit và cursor hành xử chính xác như chúng làm trên mọi bộ sưu tập khác ở đây.

id là dấu thời gian, không phải khóa duy nhất. Dữ liệu độ sâu đến mỗi 100 ms và sàn đôi khi đóng dấu hai sổ khác nhau cùng mili giây, nên một trang có thể hợp lệ chứa hai hàng với một id và hai bậc khác nhau. Phân trang xử lý trường hợp hòa — con trỏ là tập khóa, nên một mili giây chung không bao giờ bị chia qua ranh giới trang — nhưng khách hàng khóa dòng theo id một mình sẽ âm thầm bỏ một trong hai. Khóa trên dòng, hoặc trên (id, sequence within the page).

venue là tùy chọn và chọn thị trường trực tiếp: us-equities, binance (spot) hoặc binance-futures (hợp đồng vĩnh viễn). Tắt nó đi và một ký hiệu trần sẽ được giải quyết cho bạn — cổ phiếu trước, sau đó là Binance spot. Đặt tên và bạn sẽ nhận được thị trường đó hoặc không gì cả, điều bạn muốn khi một chuỗi có thể là hai công cụ.

limit là thanh nến mỗi ký hiệu. Một yêu cầu không có sẽ không được phân trang, vì việc kéo thanh tự nhiên là một cửa sổ toàn bộ và kích thước trang mặc định sẽ trả lại chuỗi ngắn — điều này không thể phân biệt với khoảng trống dữ liệu. Khi bạn phân trang, mọi chuỗi đều bị cắt tại cùng một thời điểm và pagination.next_cursor tiếp tục chính xác ở đó: không chồng chéo, không khoảng trống.

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": { … } }

Cách đánh vần một ký hiệu

Cổ phiếu và ETF là mã ticker thông thường của chúng: AAPL, SPY, BRK-B. Một cặp tiền điện tử được viết theo cách sàn giao dịch viết, vì vậy nó là BTCUSDT thay vì BTC. Một hợp đồng tương lai vĩnh viễn lấy .P hậu tố — BTCUSDT.P, AAPLUSDT.P — vì cặp spot và perp là các công cụ khác nhau giao dịch ở giá khác nhau, và một không gian ký hiệu phẳng chọn ngầm một cái cho bạn sẽ là chọn thị trường mà chiến lược của bạn đo lường.

Khung dẫn xuất

Cổ phiếu được thu thập tại 1Min và 1Day; tiền điện tử được thu thập tại 1Min. Mọi thứ khác được tổng hợp khi đọc, và một chuỗi cho biết nó là gì với derived. Một thanh tổng hợp lấy giá mở cửa của thanh đầu tiên và giá đóng cửa của thanh cuối cùng, các cực đại và cực tiểu của giá cao và thấp, và tổng khối lượng, trên các nhóm căn chỉnh theo UTC.

Giới hạn

Ba giới hạn riêng biệt, và chúng thất bại với ba mã khác nhau. Cửa sổ lịch sử của gói bạn áp dụng ở đây như mọi nơi khác — vượt quá nó, 403 HISTORY_LIMIT_EXCEEDED. Số ký hiệu mỗi yêu cầu là 3 trên Explorer, 8 trên Quant, 16 trên Research, 32 trên Desk; vượt quá thì, 402 SYMBOL_LIMIT_EXCEEDED. Và một yêu cầu đơn lẻ chỉ có thể trải dài trong khoảng thời gian mà số hàng của khung cho phép — 45 ngày tại 1Min, 180 tại 5Min, một năm tại 15Min và 1Hour, mười năm tại 1Day — trên đó nó trả về 400 WINDOW_TOO_WIDE. Phân trang với limit và cursor để duyệt phạm vi rộng hơn một yêu cầu có thể mang.

Một phản hồi thứ tư không phải là một giới hạn mà là một khoảnh khắc: 503 BARS_BUSY nghĩa là dịch vụ thanh nến đang đạt giới hạn đồng thời ngay bây giờ. Nó mang details.retry_after tính bằng giây, giống như từ chối giới hạn tốc độ, và yêu cầu tương tự thường thành công trong lần thử tiếp theo — xem như lùi lại và thử lại, không phải sự cố.

Hợp đồng tiền điện tử Kalshi — độ sâu yes/no đầy đủ mà tham chiếu không có. 21 chuỗi cho tất cả 7 tài sản: 15 phút KX{ASSET}15M, ngưỡng KX{ASSET}, và hướng KX{ASSET}D. Ngưỡng và chuỗi hướng chạy đồng thời các thị trường theo giờ, ngày và tuần — market_type mang cửa sổ thực tế của mỗi thị trường.

Bộ lọc: ?coin= (tài sản cơ sở), ?type= (cửa sổ), và chính xác ?series= (ví dụ KXBTC15M). Đối với tải xuống lịch sử, truyền start_time và end_time ở đây trước và sử dụng ticker venue gốc trả về. Không tạo id ticker Kalshi từ dấu thời gian UTC; quy ước đồng hồ ticker của venue đã thay đổi theo lịch sử.

Theo mặc định, danh sách giới hạn các thị trường có sổ lệnh được ghi lại trong cửa sổ gói của bạn, vì vậy mỗi hàng có thể truy xuất được /snapshots. Đạt ?include_uncaptured=true cho toàn bộ danh mục venue: mọi chuỗi Kalshi liệt kê, bao gồm thể thao, chính trị, kinh tế, thời tiết và giải trí. Những hàng đó mang nến, không phải sổ lệnh; depth_captured trên mỗi hàng cho biết loại bạn đang xem.

Mỗi dòng mang category, nhãn chuỗi riêng của sàn (Politics, Thể thao, Tiền điện tử, Climate and Weather, …). Lọc với ?category=politics,elections hoặc ?exclude_category=sports,crypto; cả hai đều nhận danh sách phân tách bằng dấu phẩy, so sánh không phân biệt chữ hoa chữ thường và có thể được kết hợp. Sử dụng category cho cái này, không phải base_asset: base_asset được đọc từ tiền tố chuỗi và chỉ có ý nghĩa trên hàng crypto.

Sổ đặt cược Có/Không đầy đủ mới nhất cho một mã. yes/không là [price, size] các mảng (giá bằng 0–1 đô la).

{ "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": { … } }

The lịch sử chuỗi độ sâu yes/no cho một mã thị trường chính xác đã phát hiện — cùng hình dạng hàng, sắp xếp theo thời gian nhận, phân trang con trỏ theo cửa sổ thời gian (include_count tùy chọn tham gia, tối đa 1000). Lịch sử sổ lệnh Kalshi được ghi nhận tiến về phía trước từ vòng REST polling có nhịp độ. Tần suất hiệu quả thay đổi theo bộ thị trường hoạt động và giới hạn API; nó sử dụng cùng mẫu điểm cuối lịch sử như Polymarket và Limitless /snapshots, vì vậy độ sâu Kalshi cũng có thể backtest. Truyền một chuỗi như KXBTC15M, hoặc một ticker lịch sử giả định, trả về lỗi khám phá rõ ràng thay vì trang trống gây hiểu nhầm.

Hàng giờ OHLC của giá đặt mua yes, giá đặt bán yes và giá giao dịch, cộng thêm volume và open_interest. Đây là lịch sử duy nhất tồn tại cho hầu hết danh mục Kalshi: Kalshi không cung cấp sổ lệnh lịch sử, vì vậy một thị trường đóng trước khi chúng tôi bắt đầu ghi sổ lệnh sẽ không có /snapshots và không /ticks — nhưng nó có nến, kéo dài lên đến một năm.

Có cửa sổ thời gian và phân trang con trỏ như /snapshots (tối đa 5000 hàng), giới hạn theo cửa sổ lịch sử của gói bạn. ?interval= chọn kỳ nến; chỉ 1h được ghi lại, và giá trị khác trả về lỗi rõ ràng nêu tên cái tồn tại thay vì trang trống. Nến được lưu như ghi lại và không bao giờ lấy mẫu lại, nên khoảng thời gian ngắn hơn không bao giờ tổng hợp từ dài hơn.

price là null khi không có giao dịch trong khoảng thời gian — khoảng 95% trong số đó. Các bên báo giá luôn là thực, vì vậy giờ yên tĩnh vẫn cho bạn biết vị trí sổ lệnh. Phủ sóng là thị trường lâu dài (mở đến đóng lâu hơn 24 giờ); thang giá crypto ngắn hạn được ghi lại với độ phân giải đầy đủ bởi /snapshots và /ticks thay vào đó, và yêu cầu nến của họ trả về một 404 nói như vậy.

{ "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": { … } }

So sánh cả ba sàn cùng lúc? Bắt đầu từ bộ lọc đa sàn thay vì ghép nối các cuộc gọi theo venue.

Polymarket US là thị trường hợp đồng được CFTC chỉ định và là một venue riêng biệt với Polymarket: các thị trường được khóa theo slug, không có condition_id và không asset_id, và không có gì ở đây kết nối với các bề mặt Polymarket ở trên. Chỉ dành cho các gói trả phí. Sàn này đang thử nghiệm trực tiếp: danh mục, giá và giao dịch được phục vụ trên mọi danh mục, và phạm vi sổ lệnh vẫn đang được mở rộng.

Danh mục venue, mọi danh mục, đóng mới nhất trước và phân trang con trỏ. Mỗi hàng mang theo category (thể thao, crypto, politics, climate, culture, macro, technology, finance, geopolitics, science). Lọc với ?category=politics,macro hoặc ?exclude_category=sports,crypto: phân tách bằng dấu phẩy, không phân biệt chữ hoa chữ thường, có thể kết hợp. Các bộ lọc khác: ?coin=, ?type= (15m, 1h, futures, …), ?series=, ?closed=, ?resolved=, start_time/end_time trên thời gian đóng cửa. Đối với một bản sao, ?updated_since= trả về chỉ các hàng có nội dung thay đổi kể từ thời điểm đó (một danh sách, đóng cửa, thay đổi trạng thái); mỗi hàng updated_at là dấu đó. sports_market_type là trường venue mà venue cũng điền ngoài thể thao; nó không phải bộ phân biệt thể thao, category là.

Sổ đặt lệnh mới nhất, và chuỗi sổ đã ghi nhận, cho một slug. Độ sâu trên venue này được ghi lại từ ngày bắt đầu ghi nhận và giữ trong 14 ngày; thị trường ngoài cửa sổ đó trả về 404 ở đây ngay cả khi hàng danh mục tồn tại. Phủ sóng theo thị trường: thang lên/xuống được ghi liên tục, các loại dài hạn chỉ một phần.

Giá một phút, băng ghi thực thi của venue và việc thanh toán theo từng thị trường. Giá và giao dịch tồn tại cho hầu hết các thị trường được liệt kê trong mọi danh mục; các hàng thanh toán xuất hiện khi venue báo cáo kết quả.

Limitless Exchange — một CLOB trên Base chạy các thị trường crypto lên/xuống định kỳ tại 5m và 15m. Độ sâu được ghi lại trực tiếp qua websocket sổ lệnh của nó (vì vậy ngay cả các sổ lệnh nhanh 5m cũng được ghi lại). {slug} trông giống như btc-up-or-down-15-min-1780798512077.

Vị trí mở hiện tại. Bộ lọc: ?coin= và ?type= (5m/15m).

Độ sâu L2 mới nhất cho một slug (giá đặt giảm dần, giá hỏi tăng dần):

{ "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": { … } }

The lịch sử chuỗi độ sâu cho một slug — cùng hình dạng hàng, sắp xếp theo thời gian nhận, có cửa sổ thời gian + phân trang con trỏ. Đây là lịch sử sổ lệnh được bắt tiến.

Thị trường dự đoán tiền điện tử được hỗ trợ bởi Predict.fun trong Ví Binance, được chuẩn hóa thành một không gian tên DepthFeed riêng biệt. Danh mục ban đầu bao gồm các thị trường tăng/giảm BTC, ETH và BNB.

Lọc với ?coin=btc, ?type=5m, hoặc ?status=resolved. Kết quả bao gồm ID thị trường/chủ đề, điều kiện và siêu dữ liệu token, giải quyết, kết quả thắng, khối lượng, thanh khoản, số lượng người tham gia, chuỗi và hợp đồng sàn giao dịch.

Độ sâu L2 đầy đủ mới nhất và lịch sử. Bảng chu kỳ tiêu chuẩn 15 phút BTC bắt đầu 26 Tháng Sáu 2026; việc ghi lại một phút ổn định trên các thị trường trực tiếp được theo dõi bắt đầu 26 tháng 7. Các sách chờ xử lý trước đó không thể được tái tạo từ dữ liệu thanh toán.

Xác suất, giá hiển thị và mẫu giao dịch cuối được giữ riêng và bắt đầu từ 17 tháng 7 2026. Đường dẫn giao dịch được giữ chỗ trong khi các khớp lịch sử được tái tạo từ nhật ký BNB Smart Chain và hiện trả về bộ dữ liệu lịch sử trống.

Bắt đầu tại đây cho mọi thứ liên venue. Bộ lọc trả lời câu hỏi cốt lõi — cùng một thị trường “lên hay xuống” được định giá như thế nào trên Polymarket, Kalshi và Limitless ngay bây giờ? — trong một yêu cầu đơn, vì vậy bạn không bao giờ phải ghép ba điểm cuối mỗi sàn (với ba định danh khác nhau) lại với nhau. Mỗi gói thấy tất cả ba sàn; cửa sổ lịch sử gói là điểm khác biệt duy nhất khi bạn theo dõi một ô vào lịch sử của nó.

Lưới: mỗi ô cho một tài sản với xác suất “up” mới nhất của mỗi venue, giá đặt mua/bán tốt nhất và tham chiếu thanh toán. Một sổ lệnh giữ chỗ/trống báo cáo null thay vì một 0.50 vô nghĩa.

{ "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": { … } }

Khoan sâu vào một (tài sản, cửa sổ): sổ lệnh L2 đầy đủ trên mọi venue bên cạnh nhau (books.polymarket / books.kalshi / books.limitless), cộng với chuỗi spot cơ sở và việc thanh toán price_to_beat — cuộc gọi duy nhất mà backtest đa venue hoặc màn hình arb thực sự cần.

Tổng quan chuỗi thời gian theo tài sản, đa venue (đoạn giá theo cửa sổ) — điều tạo nên biểu đồ tổng quan bảng điều khiển. Công khai, không cần khóa; chọn với ?asset=.

Chạy tối đa 10 GET /v3/ yêu cầu trong một chuyến đi vòng. Mỗi yêu cầu phụ được gửi độc lập và có trạng thái riêng.

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" }
  ] }'

Độ sâu của một hợp đồng và các thanh giá của tài sản cơ sở trong một lượt đi về là sự kết hợp mà cái này tồn tại cho — /v3/bars là một yêu cầu phụ như bất kỳ yêu cầu nào khác.

Lợi nhuận { data: [ { id, status, body }, … ] } với một lớp ngoài 200. Qua 10 yêu cầu phụ → 400 BATCH_TOO_LARGE; một yêu cầu không phải GET hoặc không phải/v3/ đường dẫn có mỗi-sub 400 BATCH_INVALID_PATH.

Cập nhật tháng 19, 2026. Xem hướng dẫn tích hợp hiện tại cho định danh, sửa lỗi, phân trang và kiểm tra tính đầy đủ.

Danh tính fixture, ứng viên và hợp đồng

Hiện có kind, outcomes và tokens vẫn giữ nguyên chuỗi thuần venue-native; kết quả và token căn chỉnh theo chỉ số trong một hàng. fixture_participants cung cấp các thành phần cố định chuẩn độc lập với loại thị trường. market_family và market_period chuẩn hóa nhãn loại được hỗ trợ mà không khẳng định các dòng, bên hoặc quy tắc tương đương. Nhãn Yes/No và Over/Under chung không được gán cho một đội. Một hợp đồng Kalshi YES một token vẫn là một token; hợp đồng NO bổ sung không tự động là đối thủ.

Các ứng viên tiền cược được đánh giá trên các giải đấu khi có thể xác định lịch thi đấu và kết quả được gán nhãn hai bên tham gia. So sánh chênh lệch nửa đơn vị, tổng và tổng đội dựa trên sports-lines-v1, contract_spec và bên kết quả. Các khoảng thời gian nửa/quý gốc ghi đè nhãn loại chung. Các đề xuất đếm gốc rõ ràng có thể chuẩn hóa về ranh giới nửa đơn vị khi giá đánh, chỉ số và chủ đề đồng thuận. Trò chơi/bộ tennis, trò chơi/bản đồ esports, phạt góc, touchdown, field goal và yard tấn công giữ chỉ số riêng biệt. Tổng điểm năm đầu tiên là tổng chạy; phạm vi hiệp riêng biệt vẫn giữ nguyên. Các dòng số nguyên/đẩy và chia, chỉ số chưa biết, hợp đồng tương lai và cược phụ không được hỗ trợ; tham khảo hợp đồng ánh xạ cho ngữ nghĩa chênh lệch ký hiệu. Hồ sơ đã xem xét hiện tại không có cặp tương đương được phê duyệt; các khóa xác nhận do đó là null. Các khóa ứng viên hỗ trợ nhóm chủ đề với quyết định giải quyết được xem xét riêng; chúng không thay thế cho sự tương đương đã xác nhận. Không cam kết ngày cho việc đối chiếu rộng hơn đã xác nhận.

Cấp cao nhất cross_venue_market_key và contract_mapping.cross_venue_market_key là bí danh giống nhau từ một ánh xạ. Đọc bằng chứng nguồn hiện tại với GET /v3/sports/markets/{condition_id}/contract; bằng chứng vắng mặt là null, và bằng chứng đã hết hạn hoặc không khớp đầu vào được đánh dấu rõ ràng. GET /v3/sports/market-families trả về bảng chuyển đổi loại có thể đọc máy.

So sánh bao gồm thời kỳ, hiệp phụ, hòa, hoãn, hủy, nguồn kết quả, tính cuối cùng của kết quả, bỏ cuộc, phạt, thay đổi sàn và các quy tắc quan trọng khác. Trích xuất chẩn đoán không phải là bằng chứng tương đương: ánh xạ xác nhận yêu cầu terms_verified: true, một băm bằng chứng và bằng chứng nguồn mới.

Với Rams vs. 49ers, danh tính người tham gia không giải quyết được các điều khoản hoãn khác nhau. Bằng chứng và chẩn đoán có thể hết hạn; đọc mã lý do hiện tại và bằng chứng nguồn thay vì mã hóa cứng trạng thái ví dụ.

Khóa ứng viên bao gồm nhận dạng sự kiện và có thể thay đổi hoặc xóa sau khi chỉnh sửa nhận dạng, dòng, khoảng thời gian hoặc nhóm. Cập nhật bằng condition_id, tiêu thụ updated_since các delta và giữ các phiên bản hàng trước cho các phép nối lịch sử. candidate_group phơi bày số lượng venue gốc và ID điều kiện; không chọn thị trường có thẩm quyền trong số nhiều danh sách gốc.

Chênh lệch quý, tổng và tổng đội được phân loại rõ ràng. Các ứng viên nhị phân ràng buộc nguồn sử dụng sports-binary-v1 và một điều kiện rõ ràng: không bao giờ suy diễn ý nghĩa từ nhãn như nrfi. Các kết quả dòng được hỗ trợ kết hợp theo bên trong ứng viên; kết quả moneyline kết hợp theo người tham gia. Xem tham khảo API thể thao cho tham số endpoint và trường phản hồi trước khi lưu các phép nối.

Phân loại hạt dòng và chất lượng dữ liệu

Một hàng là bản ghi thị trường trong danh mục. Một số hàng tiền cược Kalshi nhóm hai hợp đồng YES độc lập; các bản ghi khác hiển thị một hợp đồng. Một lịch thi đấu có thể tạo ra kết quả tiền cược riêng biệt, chênh lệch, tổng, tổng đội, cược phụ, biến thể dòng và hồ sơ điều kiện lịch sử, nên số lượng nhóm theo cross_venue_key không mong đợi khớp giữa các sàn. Sự khác biệt lớn là tín hiệu xem xét, không phải bằng chứng dòng bị thiếu hoặc trùng lặp.

resolved=false nghĩa là venue chưa đánh dấu điều kiện đó là cuối cùng; không có nghĩa ánh xạ chưa được giải quyết. Một thị trường có thể chưa giải quyết với khóa fixture ứng viên, hoặc đã giải quyết với ánh xạ null hoặc bị thu hồi. Giữ resolved, contract_mapping.status và sự hiện diện khóa như các trục riêng biệt.

Để kiểm toán, liệt kê league, scope và kind với GET /v3/sports/markets, sau đó so sánh các hàng cùng chữ ký chuẩn hóa: trận đấu, thời kỳ, người tham gia, đường, phía, loại và hồ sơ thanh toán. Dùng candidate_key cho nhóm ứng viên và cross_venue_market_key chỉ dành cho các kết nối đã xác nhận. Không bao giờ điền khóa null từ slug, tiêu đề, vị trí mảng hoặc tỷ lệ đếm hàng; giữ lại reason_codes và trạng thái bằng chứng.

Các mã sàn giao dịch có thể khác nhau cho cùng một sự kiện. Ví dụ, Kalshi kalshi-soccer-ieloak-2026-09-20 và Polymarket uslc-iel-oak-2026-09-20 yêu cầu kiểm tra fixture, người tham gia, thời gian bắt đầu và thanh toán trước khi bất kỳ kết nối nào.

Sửa lỗi tăng dần

/v3/sports/markets?updated_since= chấp nhận epoch milliseconds, ISO-8601 hoặc ngày. updated_at và updated_ms là thời gian xuất bản danh mục. Danh tính, khai mạc, thu hồi ánh xạ và gia hạn bằng chứng xuất bản cập nhật.

1. Lưu thời gian bắt đầu thăm dò và điểm kiểm tra trước đó.
2. Giữ updated_since và bộ lọc cố định trên mọi con trỏ.
3. Chèn hoặc cập nhật bởi condition_id, bao gồm các giá trị null thu hồi ánh xạ cũ.
4. Bao gồm các thị trường đã giải quyết trong quá trình kiểm tra sửa lỗi.
5. Tiến từ điểm bắt đầu thăm dò với sự chồng chéo chỉ sau khi mỗi trang thành công.

Các thay đổi được lưu giữ đối với khóa fixture, danh tính người tham gia, siêu dữ liệu loại gia đình và bằng chứng hợp đồng được tái xuất bản qua các delta danh mục. Hết hạn bằng chứng theo đồng hồ tường khác: ngừng sử dụng khóa đã xác nhận tại evidence_valid_until_ms ngay cả trước khi delta thu hồi đến. Hết hạn giữ danh tính ứng viên và người tham gia. Điều này thay thế hướng dẫn cũ rằng sửa chữa fixture có thể bỏ qua updated_at. Theo quy trình sửa lỗi ở trên và quy tắc xác thực tích hợp khi giữ hoặc làm mới ánh xạ.

Xác thực phản hồi

Kiểm tra meta.partial ngay cả sau HTTP 200. Giữ nguyên giá null, theo con trỏ mờ trong khi has_more là đúng, và không coi số lượng hoặc metadata độ phân giải là bằng chứng về tính đầy đủ toàn venue. Hàng điền trước là quan sát mang theo, không phải ghi mới.

Thời gian thực thể thao dữ liệu thị trường dự đoán — độ sâu sổ lệnh trực tiếp trên Polymarket và Kalshi, cùng với tỷ lệ cược sportsbook, điểm số trực tiếp và nguồn tin chấn thương trên các giải lớn (NBA, NFL, MLB, NHL, bóng đá, quần vợt, UFC, F1 và hơn thế nữa). Cả hai venue đều được bao gồm trên mọi cấp độ; các gói thay đổi cửa sổ lịch sử chia sẻ, thông lượng và đồng thời sổ lệnh trực tiếp. Giống nhau{ data, meta, pagination } phong bì, xác thực và phân trang con trỏ như phần còn lại của API.

Đang khám phá thị trường. Đi qua phễu: /v3/sports/leagues → /v3/sports/markets?league=… → lấy một thị trường tokens[] (mỗi cái là một kết quả asset_id) → /v3/sports/books/{asset_id}/latest cho sổ lệnh trực tiếp.

Phạm vi và trạng thái tài khoản. Quyền thể thao của gói bạn, các sàn và giải đấu theo dõi, số lượng thị trường và sổ lệnh, và cửa sổ lịch sử giữ, trong một lần gọi. Không chứa dữ liệu thị trường hay sổ lệnh; đường dẫn trên là cách đến sổ lệnh trực tiếp.

Các giải đấu chúng tôi theo dõi, mỗi giải với số lượng trận đấu và thị trường — đỉnh của phễu khám phá.

Thị trường thể thao trên Polymarket và Kalshi. Lọc với ?league= (ví dụ, nba, mlb, soccer); phân trang con trỏ như mọi điểm cuối danh sách (?limit=, ?cursor=). Mỗi thị trường mang condition_id, market_slug, outcomes, và tokens — theo kết quả asset_ids bạn gửi đến điểm cuối sổ lệnh.

{ "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": { … } }

Sổ đặt lệnh đầy đủ mới nhất được ghi nhận cho một kết quả — the asset_id là token từ thị trườngtokens[]. Thang giá đến dưới dạng bốn mảng căn chỉnh chỉ số (bid_prices với bid_sizes, ask_prices với ask_sizes) thay vì [price, size] các cặp mà tuyến crypto trả về; Những gì mỗi tuyến đường sổ lệnh chia sẻ liệt kê mọi khác biệt. Đối với sử dụng trực tiếp nhạy độ trễ, Quant và các cấp cao hơn có thể đăng ký các kênh WebSocket thể thao dưới đây.

Ảnh chụp nhanh bậc thang lịch sử cho kết quả. Truy cập với ?limit= và ?cursor=; giới hạn thời gian với ?start_time= / ?end_time= (ngắn hơn ?from= / ?to= bí danh cũng được chấp nhận). Thêm ?interval=1m để trả về ảnh chụp nhanh mới nhất trong mỗi nhóm căn chỉnh theo epoch; các đơn vị hỗ trợ là s, m, h, và d, từ một giây đến một ngày. Bỏ qua nó, hoặc dùngraw / tick, cho mỗi snapshot được ghi lại. Độ sâu thể thao được ghi trước: kho lưu trữ Polymarket bắt đầu từ 14 tháng 4 2026 và kho lưu trữ Kalshi bắt đầu từ 12 tháng 6 2026.

Giảm mẫu theo khoảng; không nội suy. Một thùng tồn tại trong phản hồi chỉ khi sổ lệnh được ghi lại bên trong nó, vì vậy một cửa sổ hai giờ tại ?interval=1m bao phủ 120 nhóm nhưng chỉ trả về các phút có dữ liệu ghi nhận. Với kết quả được báo giá không thường xuyên — thị trường còn nhiều ngày mới bắt đầu — thường là mười đến hai mươi hàng, và đó là toàn bộ băng ghi cho cửa sổ thay vì trang bị cắt ngắn. Mỗi phản hồi dùng ?interval= mang một resolution chặn để hai cái có thể phân biệt:

{ "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
  } }

Nếu buckets_filled thấp hơn nhiều buckets_in_range, kết quả được báo giá không thường xuyên — yêu cầu khoảng thời gian thô hơn, hoặc bỏ qua và đọc mọi lần ghi lại. Mật độ ghi lại theo dõi hoạt động giao dịch: một kết quả trong trò chơi đang diễn ra ghi hàng trăm đến hàng nghìn snapshot trong hai giờ, trong khi cùng kết quả ba tuần sau ghi vài chục. Vì vậy ?interval=1m trả về chuỗi gần đầy đủ mỗi phút khi trận đấu bắt đầu, và chuỗi ngắn cho thị trường chưa được giao dịch.

Thêm ?fill=ffill bên cạnh interval cho lưới dày đặc thay thế: một hàng mỗi nhóm cho toàn bộ cửa sổ, mang theo sổ lệnh cuối cùng được ghi lại vào các phút không có ghi nhận, mỗi hàng được đánh dấu filled và đóng dấu as_of_ts với thời điểm sổ lệnh được ghi lại. Tham số giống nhau, ý nghĩa giống nhau, dấu hiệu giống mọi tuyến ảnh chụp nhanh khác — xem Lấp đầy khoảng trống.

Trò chơi và bối cảnh thị trường đã giải quyết

Trận đấu và điểm số trực tiếp cho một giải đấu (ví dụ nba, nfl, soccer/eng.1), mỗi cái có các thị trường Polymarket & Kalshi liên kết.

Tài liệu trò chơi liên kết: lịch thi đấu và điểm cuối cùng, các thị trường dự đoán và thanh toán liên kết, các đường cược sportsbook và bối cảnh chấn thương. Sử dụng các tuyến đường kèm theo bên dưới khi bạn cần một lớp riêng lẻ có khối lượng lớn.

Danh sách thị trường nhúng là bản xem trước tối đa 1,000 bản ghi. Kiểm tra markets_returned và markets_truncated, sau đó theo dõi markets_url và con trỏ của nó từ đầu cho bộ đầy đủ. Đọc dữ liệu thất bại trả về 503 CATALOGUE_UNAVAILABLE; giữ các bản ghi trước đó của bạn và thử lại thay vì coi một tra cứu không khả dụng là một kết quả trống.

Thị trường trò chơi, biến động tỷ lệ, điểm số hộp, diễn biến từng pha và xác suất thắng mỗi pha.

Một thị trường chuẩn hóa với định danh venue, kết quả, ID token, tham gia trò chơi và trạng thái giải quyết.

Người chơi, props và chấn thương

Tìm kiếm thư mục vận động viên giải đấu và lấy ID vận động viên ổn định được sử dụng bởi các liên kết cược người chơi.

Hồ sơ người chơi, nhật ký thay đổi chấn thương, nhật ký điểm số hộp và props thị trường dự đoán đã phân giải thực thể.

Nguồn cấp chấn thương trực tiếp theo giải đấu — các thay đổi trạng thái trước trận làm thị trường biến động.

Tỷ lệ cược sportsbook

Dòng tiềnline, chênh lệch, tổng và dòng prop trực tiếp trên các sổ, chuẩn hóa để so sánh với giá thị trường.

Danh mục sportsbook hoạt động và độ mới nguồn.

Dòng cược thể thao lịch sử cho bốn giải: nfl (nflverse, các mùa 1999–2026) và epl, la-liga, soccer (football-data.co.uk, 2000/01 trở đi). Bất kỳ giải đấu nào khác trả về 404 SPORTS_UNKNOWN_ROUTE đặt tên bốn cái này. Một yêu cầu cần ít nhất một bộ lọc: NFL lấy season, team, từ, hoặc đến; bóng đá lấy mã mùa giải dữ liệu bóng đá (ví dụ 2324) và/hoặc team. Không có thì bạn nhận được 400 INVALID_PARAMETER nói rõ cái nào.

Sự kiện gửi từ máy chủ cho thay đổi dòng sportsbook. Gửi Accept: text/event-stream; các sự kiện đi qua khi chúng đến và kết nối vẫn mở. Sách đặt hàng thể thao sử dụng DepthFeed WebSocket chính bên dưới.

Webhook chấn thương

Đăng ký bộ nhận HTTPS với bộ lọc giải đấu và trạng thái chấn thương. Bí mật ký được hiển thị một lần. Các lần giao hàng bao gồm X-DepthFeed-Event và X-DepthFeed-Signature; xác minh chữ ký HMAC-SHA256 trên thân yêu cầu thô chính xác trước khi phân tích cú pháp 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"]}'

Liệt kê đăng ký và tình trạng giao hàng, gửi sự kiện kiểm tra đã ký, hoặc thu hồi đăng ký.

# 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 dữ liệu thị trường qua TLS

Kết nối hệ thống dữ liệu thị trường FIX hiện có với sổ lệnh chuẩn hóa từ Binance, Polymarket, Kalshi, Limitless và các kênh thể thao được hỗ trợ. Hồ sơ cung cấp ảnh chụp ban đầu, cập nhật mức giá mới/thay đổi/xóa, nhịp tim, số thứ tự liên tục và phục hồi lỗ hổng điền đầy theo sau bởi ảnh chụp mới. Nó tiêu thụ cùng nguồn cấp dữ liệu như WebSocket.

REST vẫn là giao diện khám phá và dữ liệu lịch sử. Hồ sơ FIX này bao gồm dữ liệu thị trường; nó không định tuyến lệnh hoặc cung cấp phát lại tick lịch sử. Nó không thêm phạm vi ghi nhận độc lập hoặc đảm bảo độ trễ. Dấu thời gian nguồn và dấu thời gian gửi cổng khác với nhận của khách hàng.

Đọc hồ sơ FIX hoàn chỉnh cho ký hiệu, kết quả nhị phân, trường yêu cầu, ID cấp độ xác định, giới hạn phục hồi và an toàn. Liên hệ hỗ trợ doanh nghiệp cho trạng thái cung cấp. Không đoán hostname hoặc gửi khóa API đến endpoint FIX chưa xác minh.

Một WebSocket đẩy sổ lệnh và giá trực tiếp khi chúng thay đổi. Payload khung là cùng các đối tượng JSON mà điểm cuối ảnh chụp nhanh REST trả về, vì vậy mã viết cho REST chuyển trực tiếp. Xác thực khi kết nối với X-API-Key tiêu đề, Authorization: Bearer, hoặc — cho trình duyệt, không thể đặt tiêu đề 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":…}

Các kênh

Ops: subscribe · unsubscribe (mỗi cái mất {"channels":[…]}, áp dụng nguyên tử) và ping → pong. Một trailing * phân khúc thị trường (ví dụ. book:kalshi:btc:*) đăng ký toàn bộ sàn/coin — chỉ dành cho gói Desk. Các vấn đề cấp độ Op (kênh xấu, vượt quá giới hạn đăng ký) sẽ trả về {"op":"error","code":…} khung và không bao giờ ngắt kết nối.

Kênh thể thao sử dụng định danh cụ thể và không hỗ trợ ký tự đại diện. Quant, Research và Desk cho phép một, hai và ba sportsbook đồng thời tương ứng. Mỗi khung thể thao bao gồm toàn bộ thang, venue, asset_id, dấu thời gian trao đổi/nhận, full_ladder: true, và mộtdelivery trường đặt tên nguồn của mỗi khung: polymarket_clob_ws,kalshi_orderbook_delta_ws, hoặc scoretape_relay khi bộ chuyển tiếp thể thao đang phục vụ. Sổ thể thao Kalshi được điều khiển bởi websocket delta sổ lệnh Kalshi đã xác thực, với bộ chuyển tiếp làm dự phòng, vì vậy thời gian khung theo hoạt động sàn thay vì khoảng thời gian lấy mẫu cố định. Đọc độ mới từ dấu thời gian mỗi quan sát thay vì giả định tần suất làm mới.

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

Giới hạn theo kế hoạch

Cột kênh giống nhau trên mọi hàng có lý do: kế hoạch cũng không mua sàn hay coin ở đây. Explorer phát trực tiếp bất kỳ sổ lệnh nào trên bốn sàn — nó chỉ giữ một đăng ký tại một thời điểm, nên kênh thứ hai trong cùng subscribe trả về SUB_LIMIT và không áp dụng gì. Ký tự đại diện và sổ lệnh thể thao trực tiếp là hai thứ giới hạn đăng ký đơn thuần không bao phủ.

Khung lỗi Op

Chúng đến dưới dạng {"op":"error","code":…,"message":…} và giữ kết nối mở. Chúng là mã khung, không phải trạng thái HTTP.

Mã đóng & kết nối lại

Máy chủ gửi tín hiệu ping giao thức mỗi 25 giây. Việc triển khai và chuyển đổi dự phòng làm mất kết nối theo thiết kế — xử lý ngắt kết nối → kết nối lại với độ trễ tăng dần (250ms tăng gấp đôi đến ~5s) và gửi lại các đăng ký của bạn như vòng đời bình thường, không phải đường lỗi.

Tính mới và độ trễ

Nhịp độ ghi lại, độ trễ chuyển tiếp, kích thước payload và vị trí khách hàng ảnh hưởng đến việc truyền tải đầu-cuối. Khung ts là thời gian xuất bản gateway; dấu thời gian bên trong data có thể đại diện cho sự kiện sàn, bản ghi bắt hoặc lưu trữ, tùy kênh. Tuổi nguồn và thời gian xử lý máy chủ không giống độ trễ nhận của khách.

Đo biên nhận khách hàng độc lập với đồng hồ đồng bộ, giữ nguồn gốc dấu thời gian, và báo cáo từng sàn, vùng, tải trọng và cửa sổ đo riêng biệt. Lịch sửdeploy/stream_freshness.py quan sát mô tả các lần chạy đó, thay vì đảm bảo độ trễ hiện tại cho mọi người đăng ký. Enterprise FIX sử dụng cùng nguồn feed; dấu thời gian gửi và nguồn được mô tả trong hồ sơ FIX ở trên.

Wallet Intelligence là không gian nghiên cứu chỉ đọc cho ví công khai Polymarket. Lưu danh sách theo dõi, khám phá nhà giao dịch từ bảng xếp hạng công khai Polymarket, và xem vị thế công khai, hoạt động gần đây, mẫu đã thực hiện và chỉ số cấp độ danh mục đầu tư trong một nơi. Nó không bao giờ kết nối ví, ký giao dịch hay đặt lệnh thật.

Kiểm toán thực thi sổ tiếp theo

Đối với mỗi giao dịch công khai đủ điều kiện, DepthFeed tìm sổ lệnh Polymarket đầu tiên mà nó ghi lại sau dấu thời gian hoạt động, duyệt bậc thang hiển thị với cùng số lượng hợp đồng, và báo giá phát lại, phần có thể khớp, độ trễ quan sát và sự khác biệt giá có dấu so với giao dịch công khai. Cửa sổ tra cứu là 90 giây. Một kết quả khớp bị thiếu được hiển thị là thiếu; không bao giờ được ước tính.

Điểm số là cơ học: Độ sâu còn lại nghĩa là ít nhất 95% kích thước công khai được hiển thị trong phạm vi 1¢ so với giá nhà giao dịch; Giá đã di chuyển nghĩa là ít nhất 95% còn lại nhưng ở mức khác biệt trên 1¢; Kích thước không có sẵn nghĩa là dưới 95% kích thước công khai được hiển thị.

Bản sao chuyển tiếp

Bắt đầu một bản sao giấy từ bất kỳ ví được kiểm tra nào. Chỉ các giao dịch công khai quan sát sau khi bản sao được tạo mới đủ điều kiện: DepthFeed loại trùng mỗi khớp lệnh, áp dụng tỷ lệ sao chép và giới hạn mỗi giao dịch đã cấu hình, sau đó khớp lệnh tại báo giá trực tiếp tiếp theo trong sổ giao dịch Giao dịch giấy bình thường. Tiền mặt, vị thế, P&L, đường cong vốn chủ sở hữu, bộ ngắt mạch và lịch sử thanh toán xuất hiện dưới Giao dịch giấy.

Một callback HTTPS tùy chọn nhận mỗi giao dịch sao chép thành công. Bí mật ký được hiển thị một lần. Xác minh HMAC-SHA256(timestamp.body) so với x-depthfeed-signature; dấu thời gian được gửi trong x-depthfeed-timestamp. Các điểm đến mạng nội bộ, riêng tư, có chứng thực, không phải HTTPS và chuyển hướng bị từ chối.

Giới hạn diễn giải

• Một địa chỉ công khai có thể chỉ là một ví trong danh mục đầu tư của nhà giao dịch và không chứng minh danh tính hoặc quyền sở hữu.
• Dấu thời gian hoạt động công khai không phải là dấu thời gian lệnh riêng tư. Kiểm toán đo lường những gì DepthFeed quan sát sau khi công bố, không phải độ trễ gốc của nhà giao dịch.
• Chỉ các giao dịch trong phạm vi ghi lại của DepthFeed trên Polymarket mới có thể được khớp. Các thị trường không được hỗ trợ hoặc không được ghi lại sẽ hiển thị mà không có kiểm toán.
• Phát lại tiêu thụ kích thước hiển thị theo toán học; nó không thể mô hình hóa thanh khoản ẩn, ưu tiên hàng đợi, cuộc đua hủy lệnh, phí hoặc tác động thị trường của một lệnh theo dõi thực tế.
• Xếp hạng bảng xếp hạng, P&L, vị thế và hoạt động đến từ dịch vụ dữ liệu công khai của Polymarket và có thể bị trễ, sửa đổi, không đầy đủ hoặc tạm thời không khả dụng.
• Wallet Intelligence và bản mô phỏng giấy của nó là công cụ nghiên cứu — không phải giao dịch sao chép trực tiếp, tư vấn đầu tư, khuyến nghị hay đảm bảo thực thi.

Hướng dẫn nghiên cứu ví

Bắt đầu với Hướng dẫn theo dõi ví Polymarket, sau đó so sánh phân tích ví, nghiên cứu bảng xếp hạng, và phân tích thực thi sao chép giao dịch.

Mở Trình xây dựng chiến lược để mô tả chiến lược cho trợ lý, chạy thử nghiệm lịch sử và kiểm tra kết quả. Bảng vẽ trực quan có tại chế độ xem trình tạo. Cả hai chế độ xem đều sử dụng cùng một động cơ chiến lược.

Xây dựng và chạy

1. Mô tả thị trường, điều kiện vào lệnh, thoát lệnh và kích thước vị thế trong trợ lý, hoặc kết nối các nút trên bảng vẽ.
2. Xem xét chiến lược và cài đặt thực thi được tạo trước khi chạy.
3. Chọn mẫu lịch sử có sẵn trong cửa sổ lịch sử tài khoản của bạn.
4. Kiểm tra nhật ký giao dịch, đường cong vốn chủ sở hữu, các lệnh khớp và cảnh báo chất lượng dữ liệu trước khi đưa ra kết luận.

Giả định thực thi

Kết quả phụ thuộc vào mẫu được chọn, cài đặt khớp lệnh, phí, trượt giá và kích thước vị thế. Quan sát bị thiếu và độ sâu không có sẵn ảnh hưởng đến những gì có thể mô phỏng. Kiểm tra các giả định và cảnh báo của lần chạy; kết quả lịch sử không đảm bảo khớp lệnh trực tiếp hoặc hiệu suất trong tương lai.

Tiếp tục giao dịch thử

Xem xét chiến lược trong trình tạo và sử dụng quy trình triển khai giấy để theo dõi nó với quỹ mô phỏng. Giao dịch giấy có vị thế, tiền mặt và sổ giao dịch riêng. Nó không đặt lệnh thực trên sàn. Việc sử dụng trợ lý và giới hạn chiến lược giấy phụ thuộc vào gói tài khoản của bạn.

Giao dịch giấy chạy các chiến lược tiến về phía trước trên trực tiếp thị trường với tiền ảo. Khớp lệnh, đánh dấu và thanh toán đều định giá từ sổ lệnh trực tiếp của DepthFeed — mua theo giá hỏi, bán theo giá trả, vị thế tự động thanh toán $0/$1 khi thị trường kết thúc. Mỗi chiến lược có đường cong vốn riêng, chế độ xem vị thế và nhật ký giao dịch đầy đủ.

Ba cách để giao dịch

Webhook tín hiệu

Token (hiển thị một lần khi tạo/xoay) là xác thực. Các giao dịch luôn định giá từ sổ lệnh trực tiếp tại thời điểm tín hiệu — một payload không bao giờ có thể đặt giá riêng. Thị trường được xác định bởi venue + market: một mã Kalshi, hoặc một mã token CLOB của Polymarket. Bạn có thể giao dịch bất kỳ thị trường nào trên sàn, không chỉ những cái DepthFeed ghi nhận — nếu chúng tôi không có tại chỗ, khớp lệnh được định giá từ đọc trực tiếp sổ lệnh của sàn.

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": "…" } }

Cầu dao ngắt mạch

Mỗi chiến lược có trailing dừng tối đa giảm vốn (mặc định 60%, có thể chỉnh sửa; đặt thành 0 để vô hiệu hóa). Nếu vốn chủ sở hữu trực tiếp giảm xuống dưới mức cao nhất đó, chiến lược sẽ tự động đóng vị thế tại giá hiện tại và đã tạm dừng — một điểm dừng cứng chống lại chiến lược tự giao dịch về không. Có thể tiếp tục bất cứ lúc nào; tiếp tục sẽ đặt lại mốc cao nhất về vốn hiện tại của bạn.

Giới hạn

Chiến lược đồng thời theo kế hoạch: Explorer 1 · Quant 5 · Research 15 · Desk 40. Tối đa 100 vị thế mở mỗi chiến lược; số dư bắt đầu $100–$1,000,000 (mặc định $10,000). Giá đánh dấu làm mới theo nhịp ~90 giây — đây là bộ theo dõi kiểm thử tiến, không phải sàn thực thi.

Mọi tuyến sổ lệnh — sáu tuyến crypto và venue cộng thêm thể thao — trả lời cùng một hợp đồng, nên mã viết cho một tuyến có thể chuyển sang tuyến khác bằng cách đổi đường dẫn và định danh.

• The { data, pagination, meta } phong bì và meta.request_id.
• Bộ khóa cursor phân trang và limit.
• Cửa sổ, dưới dạng start_time/end_time hoặc từ/đến.
• interval cho một sổ lệnh mỗi nhóm, và fill=ffill cho một lưới dày đặc.
• filled, as_of_ts, và as_of_ts_ms trên các hàng đã khớp.
• The resolution chặn trên bất kỳ phản hồi nào đã sử dụng interval.
• Cửa sổ lịch sử kế hoạch, và error.code enum.

Bốn điều vẫn khác nhau, tất cả đều hiển thị trong phản hồi thay vì ẩn trong hành vi.

Đây là các hình dạng mà các tích hợp hiện có được xây dựng trên đó, vì vậy chúng giữ nguyên như vậy. Sắp xếp theo dấu thời gian của hàng thay vì theo thứ tự đến và sự khác biệt sẽ không còn quan trọng.

Độ chính xác đến từ việc lấy nguồn cùng upstream mà thị trường sử dụng, nên giá trị khớp theo thiết kế.

Tất cả 7 tài sản (btc · eth · sol · xrp · doge · bnb · hype) trên mọi sàn niêm yết chúng.

Dấu thời gian là epoch-millis. exch_ts_ms = thời gian trao đổi, recv_ts_ms = thời gian nhận của chúng tôi (sự khác biệt là độ trễ ghi). Bên dưới là các cột ĐÃ LƯU TRỮ. Các tuyến tiền điện tử và sàn giao dịch kết hợp bốn mảng giá/kích thước thành bids / asks ghép các cặp trước khi trả về; các tuyến thể thao truyền qua chúng dưới dạng bốn mảng. Mọi thứ khác đến bạn dưới tên được lưu trữ.

polymarket_book — ảnh chụp nhanh sổ lệnh đầy đủ

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 — delta để phát lại giữa các ảnh chụp

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

polymarket_markets — một hàng mỗi token

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 — thanh toán

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 — sổ lệnh 20 cấp (spot & futures)

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

giá — chuỗi giá cơ sở thống nhất

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

Mọi cửa sổ gói được phục vụ từ kho trực tiếp cộng kho lạnh, nên toàn bộ cửa sổ luôn có sẵn. Desk không có giới hạn lịch sử cuộn: nó có thể truy vấn mọi bản ghi được lưu trữ từ sàn giao dịch áp dụng cho đến nguồn cấp dữ liệu trực tiếp. Các sàn giao dịch khác nhau vì các hợp đồng và việc ghi phép đã không bắt đầu cùng một ngày cho mọi tổ hợp tài sản/cửa sổ.

Lưu trữ độ sâu đầy đủ Polymarket (UTC)

Một sàn giao dịch là ngày đầu tiên một thang giá được ghi lại, không phải là ngày đầu tiên của một chuỗi không bị gián đoạn. Kho lưu trữ Polymarket chứa không có gì trước 2026-01-03, và tháng Một là năm ngày rải rác (2026-01-03 đến 01-06, và 01-24). Phạm vi liên tục hàng ngày bắt đầu 2026-02-12. Một backtest cần một chuỗi không bị gián đoạn nên bắt đầu từ đó.

Đây là những ngày sớm nhất có bậc thang đầy đủ được ghi lại, không phải tuyên bố rằng mọi tài sản/cửa sổ đều tồn tại trước ngày đó. Một snapshot trả về bậc thang đã ghi đầy đủ; nó có thể hợp lệ không chứa cấp độ nào khi thị trường đó không có lệnh nghỉ tại thời điểm đó.

Các mốc kho lưu trữ Kalshi (UTC)

Các mức sàn Kalshi là tách biệt với các mục Polymarket ở trên và là sau. Bậc Kalshi ghi nhận sớm nhất của bất kỳ chuỗi nào là 2026-01-08. Đối với chuỗi crypto 15 phút:

Chuỗi Kalshi hàng giờ, hàng ngày và hàng tuần có sàn riêng cho mỗi chuỗi, và BTC, ETH, XRP và DOGE cũng bắt đầu từ 2026-01-08 ở đó. Thay vì công bố sàn cho mỗi chuỗi, hãy coi việc khám phá là có thẩm quyền: /v3/kalshi/markets?series=KXBTC15M&start_time=…&end_time=… liệt kê chính xác các ticker có thể lấy độ sâu trong phạm vi đó, và id ticker Kalshi được venue định nghĩa, nên phải khám phá thay vì tạo từ dấu thời gian UTC.

Tần suất và độ sâu ghi nhận Kalshi không đồng đều trong kho lưu trữ. Ghi nhận hiện tại lấy toàn bộ bậc thang lên đến 100 cấp mỗi bên mỗi vài giây; các giai đoạn trước thưa hơn, và một số ngày mùa xuân 2026 chỉ có vài quan sát mỗi hợp đồng. Các hàng snapshot được lưu nguyên trạng, nên khi nghiên cứu toàn kho cần giảm mẫu lên lưới cố định và mang theo số lượng quan sát mỗi nhóm thay vì giả định khoảng cách lấy mẫu cố định.

Độ sâu sổ lệnh được ghi trực tiếp và không thể tái tạo sau đó. Truy cập lưu trữ được cung cấp qua các bề mặt truy vấn đo lường đã được tài liệu hóa; DepthFeed không cung cấp tái tạo theo yêu cầu khách hàng hoặc giao hàng lưu trữ số lượng lớn.

Bán dữ liệu lớn toàn bộ ngày UTC của kho lưu trữ dưới dạng các tệp Parquet zstd đã đóng dấu, mỗi bảng một tệp mỗi ngày, được cung cấp từ lưu trữ đối tượng qua URL ký ngắn hạn. Nó nằm bên cạnh REST API, không phải phía trước: API vẫn phục vụ cửa sổ nóng và các làn lịch sử, và các tệp lớn đảm nhận công việc "duyệt toàn bộ kho lưu trữ". Trả trước, tính giá theo GiB, và được kiểm soát bởi giấy phép dữ liệu bạn chấp nhận một lần trong bảng điều khiển.

Sản phẩm

Nhóm dòng là 5,000 dòng trên bảng sổ lệnh và 25,000 ở nơi khác, sắp xếp theo thị trường trước, để người đọc có thể đọc phạm vi một thị trường trong một tệp ngày. Bảng thể thao theo sau khi đóng dấu hàng ngày của chúng.

Định giá

Đang đóng dấu

Một ngày được liệt kê trong danh mục chỉ khi đã đóng dấu: ít nhất ba ngày tuổi, đúng một tệp dữ liệu, và ETag của nó được ghi trong danh mục. Băm danh mục là thứ bạn mua. Nếu một ngày nào đó được đóng dấu lại thì nó trở thành phiên bản mới; các liên kết đến phiên bản cũ sẽ ngừng được cấp và hàng danh mục hiển thị phiên bản mới. Thứ tự bạn đặt sẽ giữ nguyên phiên bản đã ghi của nó, và các liên kết gọi sẽ đánh dấu các mục đó superseded thay vì trả về URL.

Giấy phép

Báo giá và lệnh trả về 403 DATA_LICENCE_REQUIRED cho đến khi tài khoản chấp nhận Giấy phép dữ liệu: sử dụng nội bộ trong tổ chức của bạn, không phân phối lại hoặc bán lại, cho phép phân tích phái sinh. Chấp nhận từ bảng điều khiển hoặc với lệnh gọi bên dưới. Tài khoản chưa bật sản phẩm sẽ nhận được 404 DATA_PRODUCTS_DISABLED trên mọi tuyến đường ở đây.

Các lộ trình

Các bảng có thể bán với mức giá của chúng.

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

Tài khoản này đã chấp nhận giấy phép chưa, và phiên bản nào.

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

Ghi nhận sự chấp nhận phiên bản in trên trang giấy phép.

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"}'

Số dư trả trước dưới dạng credits và usd. Nạp tiền được thực hiện từ bảng điều khiển.

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

Ngày đã đóng dấu cho một sản phẩm giữa từ và đến (Ngày UTC, bao gồm), mỗi cái có bytes, rows, etag, version và sealed_at. Phân trang con trỏ như mọi danh sách.

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"

Định giá lựa chọn. Trả về báo giá id, total_bytes, price_credits và expires_at (15 phút). Một báo giá giữ giá, không phải tiền: bạn không cần tín dụng trả trước để yêu cầu nó. Một báo giá mới sẽ hủy các báo giá mở trước đó trừ khi chúng có thanh toán thẻ trực tiếp. Thanh toán thủ công bằng thẻ qua điểm thanh toán bên dưới, hoặc thanh toán từ số dư tín dụng của bạn. Mỗi báo giá và đơn hàng đều mang 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"}]}'

Mua qua API và thanh toán thủ công. Gửi UUID báo giá đến điểm cuối này và mở trả vềpayment_url (cũng trả về dưới dạng url) trong trình duyệt. Đây là thanh toán thẻ do Stripe lưu trữ cho chính báo giá đó, không phải phí ngay lập tức. Lặp lại yêu cầu này khi thanh toán đang hoạt động sẽ trả về cùng một liên kết với reused: true. Sử dụng 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
} }

Sau khi thanh toán thủ công, webhook đã xác minh của Stripe sẽ tạo đơn đặt hàng đã thanh toán. Thăm dòGET /v3/data/orders với giới hạn lùi lại và khớp quote_id; trang trả về của trình duyệt không chứng minh thanh toán. Sau khi một đơn hàng paid, yêu cầu liên kết tải xuống. Email tải xuống cũng được gửi đến email tài khoản. Thanh toán chưa trả hoặc hết hạn không tạo đơn trả phí. Thanh toán tín dụng trên cùng báo giá bị chặn khi thanh toán thẻ đang hoạt động.

Thanh toán báo giá. Tín dụng bị trừ ngay; đơn hàng liệt kê mọi ngày nó bao phủ.

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…"}'

Các đơn hàng của bạn, mới nhất trước, và một đơn với các mục của nó.

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

Phát hành URL có chữ ký cho từng mục trong đơn hàng. Mỗi URL có hiệu lực một giờ và là mã thông báo mang cho tệp đó, nên giữ trong hệ thống của bạn. Gọi lại bất cứ khi nào cần bộ mới, miễn phí, trong 30 ngày. Một mục có ngày đã được đóng lại sẽ trở lại với status: "reissued_new_version" và một URL mới. Một ngày không có tệp hiện tại là 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" }
] } }

Đi qua toàn bộ lịch sử độ sâu thị trường (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")

Độ sâu chéo sàn mới nhất cho BTC lên/xuống (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 được thiết kế để điều khiển bởi các tác nhân: JSON thuần qua HTTPS, một khóa Bearer, mã lỗi ổn định và không cần SDK. Một bản tóm tắt sản phẩm có thể đọc máy nằm tại /llms.txt.

Dưới dạng công cụ gọi hàm / kiểu MCP

Bao bọc bất kỳ điểm cuối nào như một công cụ — API tự mô tả đủ để một định nghĩa chung bao phủ hầu hết quy trình làm việc:

{
  "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"]
  }
}

Phần thân công cụ là một GET xác thực duy nhất:

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

Dữ liệu trực tiếp trong các đại lý

The Luồng WebSocket sử dụng ba thao tác JSON (subscribe / unsubscribe / ping) và xác thực với ?api_key= nơi không thể đặt tiêu đề — dễ dàng điều khiển từ bất kỳ môi trường chạy nào. Khung mang cùng đối tượng JSON như REST, vì vậy mã phân tích của tác nhân giống hệt cho lịch sử và trực tiếp.

Những gì đang trực tiếp, mới nhất trước:

• Trình xây dựng chiến lược. Backtest do trợ lý dẫn dắt và khung chiến lược trực quan dùng chung cùng động cơ tại /dashboard/backtest.
• Thanh giá. /v3/bars phục vụ cổ phiếu, ETF và crypto OHLCV trong cửa sổ lịch sử gói của bạn.
• Tải xuống dữ liệu lớn. Các tệp Parquet đóng dấu UTC nguyên ngày có thể được mua riêng biệt với quyền truy cập API.
• Phát trực tiếp. /v3/stream WebSocket — kênh sổ lệnh và giá trên mọi sàn, ghi nhận và truyền tải phụ thuộc sàn, đăng ký theo gói.
• Sàn Limitless. Thị trường, sổ lệnh mới nhất và snapshot độ sâu lịch sử — với 5m + 15m ghi trực tiếp qua websocket sổ lệnh.
• Kalshi mở rộng. 21 chuỗi cho tất cả 7 tài sản (15 phút, ngưỡng, và hướng — hai cái sau chạy đồng thời theo giờ/ngày/tuần); market_type được phơi bày và có thể lọc.
• API v3 đầy đủ. Thị trường Polymarket + ảnh chụp, Binance spot/futures, tải theo lô, phân trang con trỏ, thực thi lịch sử theo kế hoạch, sử dụng có đo lường.
• HTTPS công khai. https://api.depthfeed.com qua TLS.

Lịch sử có sẵn thay đổi theo sàn và chuỗi. Kiểm tra Lịch sử & phạm vi và phản hồi API để xác nhận mức tối thiểu kho lưu trữ cho khoảng thời gian yêu cầu. Có câu hỏi hoặc yêu cầu bổ sung dữ liệu? Liên hệ.