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

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

ภาพรวม API

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

API นี้เหมาะกับใคร

• บอตเทรดและทีมควอนต์ ที่ตอบสนองต่อเหตุการณ์การลิสต์ ดีลิสต์ และการเตือน และต้องการสัญญาณกระตุ้นที่เครื่องอ่านได้
• นักพัฒนาผลิตภัณฑ์แจ้งเตือนและแดชบอร์ด ที่ครอบคลุม Binance, Upbit, Bithumb และ Robinhood โดยไม่ต้องดูแลการเชื่อมต่อแยกของแต่ละกระดาน
• นักวิจัย ที่ต้องการประวัติประกาศพร้อม timestamp: ฟีด JSON ฟรี และคลังการลิสต์ล่าสุด ซึ่งแต่ละประกาศมีหน้าของตัวเองพร้อมกราฟการตอบสนองของราคา
• ไม่ได้เขียนบอต? คุณอาจต้องการแค่การแจ้งเตือน: ติดตามช่อง Telegramฟรี หรือ @cryptolistingws บน X (EN)

ตัวเลือกฟรี

• SpeedTrial — คีย์ WebSocket ฟรีบนฟีดจริง หน่วงเชิงมารยาท +1 ms; ซ่อน ticker และหัวข้อ สำหรับการวัดประสิทธิภาพ คีย์ใช้ได้ 15 วัน ต่ออายุตามคำขอ
• FreeDelayed — คีย์ WebSocket พร้อมฟีดเต็ม มีทั้ง ticker และหัวข้อ หน่วง +240 ms ฟรีเดือนแรก จากนั้น 200 USDT/เดือน รวมทุกกระดาน
• ฟีด JSON สาธารณะ — ประกาศล่าสุดในไฟล์แบบคงที่ ไม่ต้องใช้คีย์ ไม่ใช่สตรีมเรียลไทม์
• ช่อง Telegram และบัญชี X — การแจ้งเตือนฟรีสำหรับอ่าน

แพ็กเกจแบบชำระเงิน — Basic (+20 ms) และ Premium (ไม่หน่วง) — คิดราคาต่อกระดานต่อเดือนเป็น USDT: ดูราคาและเครื่องคำนวณราคา ทุกคีย์ ทั้งฟรีและแบบชำระเงิน ออกให้ตามคำขอทาง Telegram — ไม่มีการสมัครด้วยตนเอง

สร้างเองหรือใช้ API นี้

คุณสามารถรวบรวมประกาศของกระดานด้วยตัวเองได้ ซึ่งหมายถึงการสร้างและดูแลตัวรวบรวมสำหรับแต่ละกระดาน แยกวิเคราะห์หัวข้อประกาศที่เขียนให้คนอ่านในหลายภาษา จัดประเภทประกาศแต่ละชนิด และดูแลให้ทุกอย่างทำงานตลอดทั้งวันทั้งคืนเมื่อรูปแบบเปลี่ยนไป นี่เป็นทางเลือกที่เหมาะสมหากคุณเทรดกระดานเดียวและต้องการควบคุมระบบทั้งหมดเอง

ใช้ API นี้เมื่อคุณต้องการหลายกระดานในการเชื่อมต่อเดียว สคีมาที่เสถียรซึ่งดึง ticker และประเภทเหตุการณ์ไว้แล้ว การดีลิสต์และการปลดสถานะเตือนที่จัดประเภทแล้ว รวมถึงเหตุการณ์ของ Robinhood

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

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

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

รายการค่า listingType ฉบับเต็มและล่าสุดมีอยู่ในเอกสารอ้างอิงข้อความ

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

ใช้พารามิเตอร์ ?cex= บน Tokyo endpoint เพื่อสมัครรับเฉพาะกระดานที่ต้องการ ส่วน Seoul endpoint สตรีมทั้ง Upbit และ Bithumb ดังนั้นตัวกรองเดียวกันจึงใช้ได้ที่นั่นด้วย ส่วน Robinhood ให้บริการเฉพาะจาก US endpoint คือ wss://us.cryptolisting.ws ซึ่งไม่ส่งกระดานอื่นใด

wss://jp.cryptolisting.ws                    // Tokyo: Binance, Upbit, Bithumb — Robinhood อยู่บน wss://us.cryptolisting.ws
wss://jp.cryptolisting.ws?cex=binance        // Tokyo: เฉพาะ binance
wss://jp.cryptolisting.ws?cex=binance,upbit  // Tokyo: binance + upbit
wss://kr.cryptolisting.ws                    // Seoul: Upbit + Bithumb (เร็วเป็นพิเศษจากเกาหลี)

การวัด 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

กำลังสร้างบอต? ทำตามบทแนะนำทีละขั้นตอนการสร้างบอตสไนเปอร์การลิสต์ Binance ด้วย Python (EN) มีบทแนะนำการสร้างบอตการลิสต์ Upbit และ Bithumb ด้วย Python (EN)ด้วย เอกสารอ้างอิง API ฉบับเต็มครอบคลุม WebSocket API (EN) โครงสร้างข้อความ (EN) และตัวอย่างโค้ด Python, Node.js, Go และ Rust (EN)

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

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 — ขั้นที่นำไปเทรดได้ในวงจรความเสี่ยงของเกาหลี) และ Robinhood (event Robinhood Listing และ Robinhood Live ให้บริการจาก wss://us.cryptolisting.ws) เราเพิ่มกระดานตามความต้องการของผู้สมัคร ใช้พารามิเตอร์ ?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 endpoint ซึ่งส่งทั้ง Upbit และ Bithumb และโฮสต์ใน AWS N. Virginia (us-east-1a - use1-az1) ไปยัง endpoint สหรัฐฯ ซึ่งส่ง Robinhood

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

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

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

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