Changelog

Notable changes to the WebSocket feed, its message schema, and its tiers. Newest first.

Dates are the day the change landed in the service. Only user-visible changes are listed — if a change would alter what your client receives or how you connect, it belongs here.

2026-11-11

USDC-only Binance Futures contracts are no longer listings; faster Upbit, Robinhood and Bithumb detection

• Binance Futures announcements that only launch or delist a USDC contract (for example HYPEUSDC, TRXUSDC) are now sent as not_listing, with no ticker.
• If the same announcement also includes the USDT contract (XUSDT and XUSDC), the token is kept, as before.
• Upbit and Robinhood detection: major upgrades — events now arrive faster.
• Bithumb detection is ~30 ms faster.
• No change to the message schema, API keys or limits.

2026-10-21

SpeedTrial keys now last 15 days; FreeDelayed is free for the first month, then 200 USDT/month

• SpeedTrial keys are now issued for 15 days, renewable on request (previously 1 week). Nothing changed in what the tier delivers.
• FreeDelayed is now free for the first month, then 200 USDT per month, with all exchanges included. Nothing changed in what the tier delivers: the full feed, with a +240 ms delay.
• Time left on a key is still published in welcome.expiresInSecs.

2026-10-13

Tokyo endpoint renamed to wss://jp.cryptolisting.ws

• The Tokyo endpoint has a new hostname: wss://jp.cryptolisting.ws. It is live now and serves the same feed — same API keys, same message schema, same limits. The three regional endpoints now share one naming scheme: jp., kr. and us..
• Reason: an infrastructure upgrade for faster, more consistent delivery.
• Action required before 2026-10-31: replace wss://cryptolisting.ws with wss://jp.cryptolisting.ws in your client and reconnect. Website, docs and public feed URLs (https://cryptolisting.ws/…) are unchanged. The address behind the name is the same (16.76.89.185), so an IP allowlist needs no update; if you allowlist by hostname or pin the certificate, add jp.cryptolisting.ws.
• The old name wss://cryptolisting.ws stops delivering the feed on 2026-10-31 (UTC). From that date a connection to it only gets a notice pointing to the new endpoint.
• Until then both names reach the same endpoint, so the per-key connection limits and the 5-second reconnect cooldown count across the two names together — see Rate Limits.
• Seoul (wss://kr.cryptolisting.ws) and US (wss://us.cryptolisting.ws) are unchanged.

2026-10-07

Robinhood events on the public feeds, Telegram and X

• wallet_listing and cex_listing now also appear in the public JSON feed, the Atom feed and on Latest Listings, one page per event, and are posted on the public Telegram channel and X account.
• JSON consumers that whitelist type values must add them — see Public JSON & Atom Feeds.
• WebSocket delivery is unchanged: Robinhood is served by wss://us.cryptolisting.ws only.

2026-09-14

Faster fan-out, faster Upbit detection, Robinhood launched (beta)

• Fan-out latency. The Tokyo and Seoul dispatch servers were upgraded and tuned; events now reach every subscriber noticeably sooner after detection. No change to the protocol, messages or tiers.
• Upbit detection is ~1.5 ms faster. Same events, same schema — they just arrive earlier.
• Robinhood launched, in beta, on wss://us.cryptolisting.ws (see 2026-09-11 below): wallet_listing (Robinhood Listing) when a token is added to Robinhood but is not tradable yet on Robinhood, cex_listing (Robinhood Live) when it becomes tradable on Robinhood. A wallet_listing is not a promise that trading will open on Robinhood. Same API key, same tiers, same message envelope. Beta means we are still validating it on live events — feedback welcome.
• Reminder: treat 60 s without any frame (no PING, no heartbeat) as a dead connection and reconnect — see Error Handling.

2026-09-13

Tokyo host migrated — check your dead-connection handling

• The Tokyo endpoint (wss://cryptolisting.ws) moved to a new host. Its public IP changed to 16.76.89.185 (Seoul, kr.cryptolisting.ws, now resolves to 15.165.135.192); if you pinned an IP in a firewall, update it — the hostnames are the contract, not the addresses.
• During the move the old host was stopped, so open connections did not receive a close frame. Clients that rely only on their library’s close/error callback stayed on a dead socket and received nothing afterwards. Treat 60 s without any frame (no PING, no heartbeat) as a dead connection and reconnect — the docs said the opposite (“no application-level watchdog needed”); that guidance was wrong for this case and is corrected in Error Handling. Python websockets users with the default ping_interval/ping_timeout were already covered.

2026-09-11

Robinhood, on a new US endpoint

• wss://us.cryptolisting.ws (AWS N. Virginia, us-east-1a - use1-az1) carries Robinhood — and only Robinhood. Tokyo and Seoul are unchanged; ?cex=robinhood there yields an empty intersection. Same API key, same tiers, same message envelope. See Endpoints.
• Two new listingType values, both publisher: "robinhood": wallet_listing (Robinhood Listing) — the token is added to Robinhood but is not tradable yet on Robinhood (trading may open minutes, days or weeks later, or never) — and cex_listing (Robinhood Live) — the token is tradable on Robinhood. A handler that switches on listingType with a default branch needs no change; one that whitelists types must add them. See Listing types.
• Pricing: Robinhood is priced like Upbit (Basic 400, Premium 750 USDT per month). New all-four-exchanges bundles: 1000 USDT per month on Basic, 1900 on Premium. See Pricing.

2026-09-04

Bithumb on the Seoul endpoint

• wss://kr.cryptolisting.ws now carries Upbit + Bithumb. It was Upbit-only. Binance is still dispatched from the Tokyo endpoint only. See Endpoints.
• Bithumb on Seoul carries the same three types as on Tokyo — spot_listing, spot_delisting, caution_released. Message schema, field names and timestamps are unchanged.
• If you connect to Seoul without ?cex=, you now receive Bithumb too. ?cex=upbit was a no-op on that endpoint; it is now a real filter. Add it if your handler assumes every message there is Upbit — or branch on publisher, which has always been the safer test. See Exchange Filtering.
• Announcements carry no id, and the two endpoints deduplicate independently: a bot connected to Tokyo and Seoul now receives each Bithumb announcement twice. Keep one endpoint per bot.

2026-08-22

Upbit multi-token alerts, new markets field, faster dispatch

• Upbit announcements covering several tokens now arrive as a single alert, with every token listed comma-separated in ticker.
• New optional markets field on Upbit spot listings: which markets the listing opens — KRW, BTC, USDT, or a combination, always in that order. If it is absent we could not identify them; it never means the listing has none. See Announcement.
• Upbit announcements are ~1.3 ms faster from detection to dispatch. Message content and timestamps unchanged.
• If your client rejects unknown JSON fields, it needs a one-line change. Most decoders ignore them by default. The notable exception is Jackson 2.x in Java, where FAIL_ON_UNKNOWN_PROPERTIES is enabled out of the box — add @JsonIgnoreProperties(ignoreUnknown = true) to your message class, or disable the feature on your ObjectMapper. Also check for opt-in strict modes you may have enabled yourself: Go’s Decoder.DisallowUnknownFields(), serde’s deny_unknown_fields, zod’s .strict(), or a validator configured with additionalProperties: false. Our published schema has always set additionalProperties: true — see /docs/asyncapi.yaml.
• Delivered on every tier, SpeedTrial included, with the same value as on the paid tiers — it names a quote market, not a token, so it is not redacted alongside title and ticker.

2026-08-02

Two new message types: changelog and renewal_notice

• changelog — a new message type for service announcements (schema changes, maintenance windows). Delivered to every subscriber on every tier, SpeedTrial included, with no redaction and none of the per-tier delivery delay. An entry is valid for a window counted in days: you receive it immediately if connected when it is published, otherwise on your next connection while it is still valid — once either way. It carries id, title, an optional version, and dispatchTimestampUs. Deduplicate on id: the same entry can legitimately arrive twice if you connect to both endpoints, or across a service restart. See Changelog.
• renewal_notice — sent when less than 24 h remain on your API key: right after the welcome frame if you connect inside that window, and also written to an already-open session at the moment the threshold is crossed, so a long-lived connection is told without having to reconnect. It carries title and dispatchTimestampUs, and no ticker. See Renewal notice.
• Neither type carries ticker, publisher or listingType. Switch on type and ignore values you don’t know — never let an unrecognised message reach your trading logic.

SpeedTrial announcements carry a +1 ms courtesy delay

• Announcements delivered on the SpeedTrial tier are now sent ~1 ms after paid tiers, so paying subscribers are served first. Everything else is unchanged: same dispatch pipeline, same detectedTimestampUs / dispatchTimestampUs precision, same redaction of ticker and title on listing-type events. The Delivery delay column in Tier behavior now reads +1 ms instead of None.
• Heartbeats are not affected on any tier — only announcements are delayed.
• The upgrade notice carried in title on SpeedTrial now states the delay and the reason for it, so the behaviour is visible in the message itself and not only in this changelog.
• No action required. Benchmarks run on SpeedTrial should account for this ~1 ms when comparing against a paid tier; the timestamps in each message remain exact, so detection-to-dispatch stays directly measurable.
• premium is unchanged and still has no added delay.

2026-07-13

Free-tier keys are 1-week and renewable

• SpeedTrial and FreeDelayed keys are issued for 1 week, renewable on request. They were previously advertised as free for an unlimited period. Nothing changed in what the two tiers deliver — only how long a key stays valid before renewal. Ask on @CLWfeed to renew. Time left on a key is published in welcome.expiresInSecs.
• Documented the default distinct-IP allowance per key: 1 (was described as “configurable”). The per-IP cap (3) and absolute cap (20) are unchanged. See Rate Limits.

2026-06-18

not_listing is Binance-only

• Upbit was removed from the not_listing row of every event-type table. Upbit announcements are delivered as spot_listing, spot_delisting, or caution_released — never not_listing. Documentation fix; no dispatch behaviour changed. See Listing types.

2026-06-17

Announcement channel is @CLWfeed

• The Telegram channel for keys, support, and breaking-change notices is @CLWfeed.

2026-06-16

Seoul endpoint is Upbit-only

• Documented that wss://kr.cryptolisting.ws carries Upbit only. Bithumb is dispatched from the Tokyo endpoint (wss://cryptolisting.ws), as is Binance. If your bot needs Bithumb or Binance, connect to Tokyo. See WebSocket API.

2026-06-12

Upbit stream narrowed to actionable signals

• On both endpoints, the Upbit stream carries only the events that drive trades. Upbit notices that are not a listing, delisting, or caution release are no longer broadcast to subscribers. See Listing types and Upbit only.

2026-06-09

Per-IP connection cap lowered to 3

• The per-key, per-IP concurrent-connection cap went from 5 to 3. The absolute cap across all IPs (20) is unchanged. welcome.maxConnectionsPerIp reports the live value — read it rather than hard-coding. See Rate Limits.

2026-06-06

SpeedTrial and FreeDelayed tiers

• The free tier is now SpeedTrial: same dispatch path as premium with zero added delay, but ticker is "" and title carries an upgrade notice on every event except not_listing. All other fields — publisher, listingType, microsecond timestamps — stay fully accurate, so detection speed remains independently verifiable.
• New FreeDelayed tier: the full feed, title and ticker included, free, with a +240 ms delivery delay on announcements. Heartbeats are unaffected.
• welcome.tier now returns SpeedTrial, FreeDelayed, basic, or premium. Clients that matched on the old free string must be updated. See Tier behavior.

2026-05-03

Caution lifecycle narrowed to two stages

• Upbit and Bithumb both run a multi-stage caution lifecycle on tokens already trading (pre-warning, designation, extension, release, delisting). The feed carries the two stages that drive trades: caution_released and spot_delisting. Intermediate stages are kept off the bus.
• Composite announcements covering several tickers across stages are split into multiple WebSocket events with distinct listingType values. See Listing types.

2026-05-02

Risk events: caution_released and Monitoring Tag

• New listingType value caution_released (Bithumb, Upbit) — a caution designation being lifted, historically a positive technical signal.
• New listingType values monitoring_tag_extend and monitoring_tag_remove (Binance) — a token entering or leaving Binance’s Monitoring Tag.
• Clients validating listingType against a closed list had to widen it. This is the change the forward-compatibility rule exists for: unknown listingType values must be inert, not fatal. See Listing types.

2026-04-30

Seoul endpoint

• wss://kr.cryptolisting.ws went live in AWS Seoul (ap-northeast-2c, apne2-az3), alongside the existing Tokyo endpoint. It removes the Seoul → Tokyo network hop for Korea-based bots trading Upbit. The same API key authenticates on both endpoints; connection caps are tracked independently per endpoint. Pick one endpoint per bot. See Endpoints.

2026-04-13

abnormalDetectionLatency flag

• Announcements carry a boolean abnormalDetectionLatency. true means the exchange publish → detection interval was abnormally high for that event. The payload stays valid — treat the flag as a hint that the event may be stale by the time it reaches you. See abnormalDetectionLatency.

2026-04-12

Test announcements use DUMMYTOKEN

• {"type":"test"} returns a test_announcement with the ticker DUMMYTOKEN. It is identical in shape to a real announcement and always carries the full payload regardless of tier — use it to validate a parser on any tier, SpeedTrial included. See Test Announcement.