Niêm yết crypto API thông báo

Một WebSocket API thời gian thực cho các thông báo và tin niêm yết của sàn crypto. Kết nối và nhận cảnh báo JSON có cấu trúc cho tin niêm yết Binance, Upbit, Bithumb.

Tổng quan API

CryptoListing.ws cung cấp hai điểm kết nối WebSocket truyền các thông báo và tin niêm yết theo thời gian thực từ nhiều sàn giao dịch tiền mã hoá. API được thiết kế cho các hệ thống giao dịch tự động cần nhận thông báo niêm yết mới nhanh nhất có thể. Cùng một API key xác thực trên cả hai điểm kết nối — hãy chọn theo vị trí của bot.

Định dạng tin nhắn

Mỗi tin thông báo chứa ticker, sàn, loại niêm yết và ba dấu thời gian chính xác đến micro-giây:

{
  "type": "announcement",
  "title": "Binance Will List TOKEN (TOKEN)",
  "ticker": "TOKEN",
  "publisher": "binance",
  "listingType": "spot_listing",
  "detectedTimestampUs": 1710345000005000,
  "dispatchTimestampUs": 1710345000006000
}

Các loại niêm yết

Lọc theo sàn

Dùng tham số truy vấn ?cex= trên điểm kết nối Tokyo để chỉ đăng ký một số sàn nhất định. Điểm kết nối Seoul vốn chỉ phát các thông báo Upbit, nên bộ lọc là tuỳ chọn ở đó.

wss://cryptolisting.ws                       // Tokyo: tất cả các sàn (Binance, Upbit, Bithumb)
wss://cryptolisting.ws?cex=binance             // Tokyo: chỉ binance
wss://cryptolisting.ws?cex=binance,upbit       // Tokyo: binance + upbit
wss://kr.cryptolisting.ws                    // Seoul: chỉ Upbit (siêu nhanh từ Hàn Quốc)

Đo độ trễ

Mỗi thông báo bao gồm hai dấu thời gian tính bằng micro-giây kể từ UNIX epoch. Tính độ trễ của bạn:

dispatch_delay  = dispatchTimestampUs - detectedTimestampUs
network_delay   = your_receive_time  - dispatchTimestampUs
total_latency   = your_receive_time  - detectedTimestampUs

Vì sao nên chọn API thông báo niêm yết này?

Khác với các API polling dựa trên REST hay các bot Telegram, WebSocket API của chúng tôi phân phối tin niêm yết ngay khoảnh khắc chúng được phát hiện. Broadcast zero-copy nghĩa là tin thông báo được tuần tự hoá một lần và chia sẻ cho tất cả người đăng ký — không có overhead tuần tự hoá riêng cho từng client. Kiến trúc này đạt độ trễ phân phối siêu nhanh một cách nhất quán bất kể số lượng người đăng ký. Đọc thêm về từng sàn: tin niêm yết Binance, thông báo niêm yết Upbit, tin niêm yết Bithumb.

Câu hỏi thường gặp

API dùng giao thức nào?

WebSocket (RFC 6455) qua TLS 1.2+. Xác thực được thực hiện qua header HTTP X-API-Key trên yêu cầu upgrade. Tin nhắn là JSON UTF-8 trong binary frame. Cùng một API key xác thực trên cả hai điểm kết nối — hãy chọn theo vị trí của bot, không theo sàn bạn giao dịch.

Những sàn nào được hỗ trợ?

Binance (niêm yết spot, niêm yết futures, huỷ niêm yết, HODLer airdrop, Monitoring Tag extend / remove), Upbit và Bithumb (niêm yết spot thị trường KRW, gỡ cảnh báo, và huỷ niêm yết spot — các giai đoạn có thể giao dịch của vòng đời cảnh báo Hàn Quốc). Các sàn khác được thêm dựa trên nhu cầu của người đăng ký. Dùng tham số truy vấn ?cex= trên điểm kết nối Tokyo để lọc.

Tôi xác thực bằng cách nào?

Bao gồm header X-API-Key trong yêu cầu upgrade WebSocket. Lấy khoá bằng cách liên hệ chúng tôi trên Telegram tại @CLWfeed. Cùng một khoá hoạt động trên cả hai điểm kết nối. Xem tài liệu Xác thực để có ví dụ code.

Độ trễ tin nhắn là bao nhiêu?

Độ trễ phân phối là siêu nhanh. Mỗi thông báo mang các trường detectedTimestampUs và dispatchTimestampUs chính xác đến micro-giây để bạn tự đo hiệu năng end-to-end. Độ trễ mạng phụ thuộc vào vị trí bot của bạn: máy đặt tại AWS Tokyo (ap-northeast-1a - apne1-az4) có độ trễ end-to-end thấp nhất tới điểm kết nối Tokyo, và máy đặt tại AWS Seoul (ap-northeast-2c - apne2-az3) tới điểm kết nối Upbit Seoul.

Hai điểm kết nối khác nhau ra sao?

wss://cryptolisting.ws (Tokyo) truyền feed đầy đủ và là điểm kết nối toàn cầu mặc định. wss://kr.cryptolisting.ws (Seoul) chỉ truyền Upbit và được tối ưu cho các bot giao dịch đặt cùng vị trí ở Hàn Quốc — nó loại bỏ chặng mạng Seoul→Tokyo ở phía phát hiện. Giới hạn số kết nối và giới hạn tốc độ được tính độc lập trên mỗi điểm kết nối.

Điều gì xảy ra nếu mất kết nối?

Máy chủ gửi một heartbeat mỗi 30 giây; client nên gửi WebSocket ping với cùng nhịp đó. Khi mất kết nối, hãy kết nối lại với exponential backoff (thường bắt đầu ở 1s, nhân đôi tới 30s). Các niêm yết được phát trong lúc bạn mất kết nối sẽ KHÔNG được phát lại — để có bản ghi đối soát các lần phát hiện trước, xem các lần phát hiện mới nhất.