Crypto Listing Announcement API

A real-time WebSocket API for crypto exchange listing announcements and notices. Connect and receive structured JSON alerts for Binance, Upbit, Bithumb listing notices.

API overview

CryptoListing.ws provides two WebSocket dispatch endpoints that stream real-time listing announcements and notices from multiple cryptocurrency exchanges. The API is designed for automated trading systems that need the fastest possible notification of new exchange listing announcements. Same API key authenticates on both endpoints — pick by your bot's location.

Message format

Every announcement message contains the ticker, exchange, listing type, and three microsecond-precision timestamps:

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

Listing types

Exchange filtering

Use the ?cex= query parameter on the Tokyo endpoint to subscribe to specific exchanges only. The Seoul endpoint already streams Upbit announcements exclusively, so the filter is optional there.

wss://cryptolisting.ws                       // Tokyo: all exchanges (Binance, Upbit, Bithumb)
wss://cryptolisting.ws?cex=binance             // Tokyo: binance only
wss://cryptolisting.ws?cex=binance,upbit       // Tokyo: binance + upbit
wss://kr.cryptolisting.ws                    // Seoul: Upbit only (ultra-fast from Korea)

Latency measurement

Every announcement includes two timestamps in microseconds since UNIX epoch. Calculate your latency:

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

Why choose this listing announcement API?

Unlike REST-based polling APIs or Telegram bots, our WebSocket API delivers listing notices the instant they are detected. Zero-copy broadcast means the announcement message is serialized once and shared across all subscribers — no per-client serialization overhead. This architecture achieves consistent ultra-fast dispatch latency regardless of subscriber count. Read more about specific exchanges: Binance listing notices, Upbit listing announcements, Bithumb listing notices.

FAQ

What protocol does the API use?

WebSocket (RFC 6455) over TLS 1.2+. Authentication is done via the X-API-Key HTTP header on the upgrade request. Messages are UTF-8 JSON in binary frames. The same API key authenticates on both endpoints — pick by your bot's location, not by the exchange you trade.

Which exchanges are supported?

Binance (spot listings, futures listings, delistings, HODLer airdrops, Monitoring Tag extend / remove), Upbit and Bithumb (KRW market spot listings, caution releases, and spot delistings — the trade-actionable stages of the Korean caution lifecycle). More exchanges are added based on subscriber demand. Use the ?cex= query parameter on the Tokyo endpoint to filter.

How do I authenticate?

Include the X-API-Key header in the WebSocket upgrade request. Get your key by contacting us on Telegram at @cryptolistingwebsocket. The same key works on both endpoints. See the Authentication docs for code samples.

What is the message latency?

Dispatch latency is ultra-fast. Each announcement carries microsecond-precision detectedTimestampUs and dispatchTimestampUs fields so you can independently measure end-to-end performance. Network latency depends on your bot's location: hosts in AWS Tokyo (ap-northeast-1a - apne1-az4) get the lowest end-to-end latency to the Tokyo endpoint, and hosts in AWS Seoul (ap-northeast-2c - apne2-az3) to the Seoul Upbit endpoint.

How do the two endpoints differ?

wss://cryptolisting.ws (Tokyo) streams the full feed and is the default global endpoint. wss://kr.cryptolisting.ws (Seoul) streams Upbit only and is optimized for trading bots co-located in Korea — it eliminates the Seoul→Tokyo network hop on the detection side. Connection caps and rate limits are tracked independently per endpoint.

What happens if the connection drops?

The server sends a heartbeat every 30 seconds; clients should send WebSocket pings on the same cadence. On disconnect, reconnect with exponential backoff (typically starting at 1s, doubling up to 30s). Listings emitted while you were disconnected are NOT replayed — for an audit trail of past detections, see latest detections.