ประกาศลิสต์คริปโต API

WebSocket API เรียลไทม์สำหรับประกาศและ notice การลิสต์ของกระดานคริปโต เชื่อมต่อแล้วรับการแจ้งเตือน JSON แบบมีโครงสร้างสำหรับประกาศลิสต์ของ Binance, Upbit, Bithumb

ภาพรวม API

CryptoListing.ws มี WebSocket endpoint สองตัว ที่สตรีมประกาศและ notice การลิสต์แบบเรียลไทม์จากหลายกระดานคริปโต API นี้ออกแบบมาเพื่อ ระบบเทรดอัตโนมัติ ที่ต้องการการแจ้งเตือนประกาศลิสต์ใหม่ของกระดานที่เร็วที่สุด API key เดียวยืนยันตัวตนได้ทั้งสอง endpoint — เลือกตามตำแหน่งของบอทคุณ

รูปแบบข้อความ

ทุกข้อความประกาศประกอบด้วย ticker, กระดาน, ประเภทการลิสต์ และ timestamp ระดับไมโครวินาทีสามค่า:

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

ประเภทการลิสต์

การกรองกระดาน

ใช้พารามิเตอร์ ?cex= บน Tokyo endpoint เพื่อสมัครรับเฉพาะกระดานที่ต้องการ ส่วน Seoul endpoint สตรีมเฉพาะประกาศ Upbit อยู่แล้ว ดังนั้นการกรองจึงเป็นทางเลือกที่นั่น

wss://cryptolisting.ws                       // Tokyo: ทุกกระดาน (Binance, Upbit, Bithumb)
wss://cryptolisting.ws?cex=binance             // Tokyo: เฉพาะ binance
wss://cryptolisting.ws?cex=binance,upbit       // Tokyo: binance + upbit
wss://kr.cryptolisting.ws                    // Seoul: เฉพาะ Upbit (เร็วเป็นพิเศษจากเกาหลี)

การวัด latency

ทุกประกาศมี timestamp สองค่าในหน่วย ไมโครวินาทีนับจาก UNIX epoch คำนวณ latency ของคุณได้:

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

ทำไมต้องเลือก API ประกาศลิสต์นี้?

ต่างจาก API แบบ REST polling หรือบอท Telegram, WebSocket API ของเราส่ง notice การลิสต์ในทันทีที่ตรวจจับได้ Broadcast แบบ zero-copy หมายความว่าข้อความประกาศถูก serialize เพียงครั้งเดียวและแชร์ให้ผู้สมัครทุกราย — ไม่มี overhead การ serialize รายไคลเอนต์ สถาปัตยกรรมนี้ให้ latency การส่งที่เร็วเป็นพิเศษอย่างสม่ำเสมอไม่ว่าจะมีผู้สมัครมากแค่ไหน อ่านเพิ่มเติมเกี่ยวกับแต่ละกระดาน: notice การลิสต์ Binance, ประกาศลิสต์ Upbit, notice การลิสต์ Bithumb

คำถามที่พบบ่อย

API ใช้โปรโตคอลอะไร?

WebSocket (RFC 6455) บน TLS 1.2+ การยืนยันตัวตนทำผ่าน HTTP header X-API-Key ในคำขอ upgrade ข้อความเป็น UTF-8 JSON ใน binary frame API key เดียวกันยืนยันตัวตนได้ทั้งสอง endpoint — เลือกตามตำแหน่งของบอทคุณ ไม่ใช่ตามกระดานที่คุณเทรด

รองรับกระดานใดบ้าง?

Binance (การลิสต์ spot, การลิสต์ futures, การดีลิสต์, HODLer airdrop, Monitoring Tag extend / remove), Upbit และ Bithumb (การลิสต์ spot ตลาด KRW, การปลดสถานะเตือน และการดีลิสต์ spot — ขั้นที่นำไปเทรดได้ในวงจรความเสี่ยงของเกาหลี) เราเพิ่มกระดานตามความต้องการของผู้สมัคร ใช้พารามิเตอร์ ?cex= บน Tokyo endpoint เพื่อกรอง

ยืนยันตัวตนอย่างไร?

ใส่ header X-API-Key ในคำขอ upgrade ของ WebSocket รับ key ได้โดยติดต่อเราทาง Telegram ที่ @CLWfeed key เดียวกันใช้ได้ทั้งสอง endpoint ดู เอกสารการยืนยันตัวตน สำหรับตัวอย่างโค้ด

Latency ของข้อความเท่าไร?

Latency การส่งเร็วเป็นพิเศษ ทุกประกาศมีฟิลด์ detectedTimestampUs และ dispatchTimestampUs ความละเอียดระดับไมโครวินาที เพื่อให้คุณวัดประสิทธิภาพ end-to-end ได้ด้วยตัวเอง Network latency ขึ้นกับตำแหน่งของบอท: โฮสต์ใน AWS Tokyo (ap-northeast-1a - apne1-az4) ได้ latency end-to-end ต่ำสุดไปยัง Tokyo endpoint และโฮสต์ใน AWS Seoul (ap-northeast-2c - apne2-az3) ไปยัง Seoul Upbit endpoint

สอง endpoint ต่างกันอย่างไร?

wss://cryptolisting.ws (Tokyo) สตรีมฟีดเต็มและเป็น endpoint ทั่วโลกโดยปริยาย ส่วน wss://kr.cryptolisting.ws (Seoul) สตรีมเฉพาะ Upbit และปรับแต่งมาเพื่อบอทเทรดที่ co-located ในเกาหลี — ขจัด network hop โซล→โตเกียวในฝั่งการตรวจจับ เพดานการเชื่อมต่อและ rate limit ถูกนับแยกกันในแต่ละ endpoint

ถ้าการเชื่อมต่อหลุดจะเกิดอะไรขึ้น?

เซิร์ฟเวอร์ส่ง heartbeat ทุก 30 วินาที ไคลเอนต์ควรส่ง WebSocket ping ในจังหวะเดียวกัน เมื่อหลุดการเชื่อมต่อ ให้ reconnect ด้วย exponential backoff (โดยทั่วไปเริ่มที่ 1 วินาที เพิ่มเป็นสองเท่าจนถึง 30 วินาที) การลิสต์ที่ส่งออกไปตอนคุณหลุดการเชื่อมต่อจะไม่ถูกส่งซ้ำ — สำหรับบันทึกย้อนหลังของการตรวจจับที่ผ่านมา ดู การตรวจจับล่าสุด