New: Seoul Endpoint for Upbit Announcements
Last updated
We're adding a second endpoint dedicated to Upbit announcements.
Until now, every CryptoListing.ws WebSocket connection terminated in AWS Tokyo. That works well for Binance and Bithumb, but Upbit is a Korean exchange — so for Korea-based trading bots there was an avoidable network detour. The Seoul endpoint removes it for Upbit events.
The new endpoint
"wss://kr.cryptolisting.ws" # AWS Seoul (ap-northeast-2c — apne2-az3) — Upbit only
Same API key as the Tokyo endpoint. Same message schema. The Seoul endpoint streams Upbit announcements only, so the ?cex=upbit filter is optional there.
Rate limits and connection caps are per-endpoint
Each region tracks its own rate-limit and connection budget. Connections, message rates, IP caps, and cooldowns on Tokyo do not count against Seoul, and vice-versa.
A key with a 3-connection-per-IP cap can hold 3 on Tokyo and 3 on Seoul (6 total). A cooldown on Tokyo does not gate Seoul. Full numbers per tier — SpeedTrial, FreeDelayed (full feed, +240 ms), Basic, and Premium — are in the rate-limits reference.
How to migrate from Tokyo to Seoul (for Korea-based bots)
If your trading bot is hosted in Korea (typically AWS Seoul, ap-northeast-2), connecting to wss://kr.cryptolisting.ws instead of wss://cryptolisting.ws eliminates the Seoul→Tokyo network hop on the detection side for Upbit announcements. The same API key works on both endpoints. The Seoul endpoint streams Upbit only — keep the Tokyo connection if you also need Binance or Bithumb.
Run both endpoints in parallel
For maximum coverage, open one connection to each endpoint simultaneously. Filter the Tokyo connection to ?cex=binance,bithumb to avoid duplicate Upbit events:
# Two connections, no duplicates tokyo = WebSocketApp("wss://cryptolisting.ws?cex=binance,bithumb", header=["X-API-Key: ..."], ...) seoul = WebSocketApp("wss://kr.cryptolisting.ws", header=["X-API-Key: ..."], ...)
What about Bithumb?
Bithumb is currently only dispatched from Tokyo. For Bithumb-only bots in Korea, the network round-trip Korea→Tokyo→Korea is the dominant latency component — see Bithumb listing alerts for details.
Why endpoint location matters for Upbit
Upbit is a Korean exchange, and its public announcement channel lives in Korea. When your bot and the endpoint it connects to are both close to that infrastructure, the signal has less physical distance to travel before your code sees it. Networking is bound by geography: every network hop and every kilometre of fibre adds round-trip time. A round-trip between Seoul and Tokyo is short in human terms but meaningful when a price move resolves in seconds.
The Seoul endpoint runs in AWS Seoul (region ap-northeast-2), in the apne2-az3 availability zone. For a bot co-located in the same region, dispatch of an Upbit announcement no longer crosses the sea to Tokyo and back. AWS's regional layout is documented in AWS's global infrastructure reference.
Upbit listings and the Korean retail market
Why build a dedicated Upbit endpoint at all? Because Upbit listing notices are among the most powerful catalysts in crypto. Upbit dominates Korean spot volume, and its KRW market is fed by a concentrated, fast-moving retail base. A single Upbit listing can send a token sharply higher, sometimes producing the kimchi premium — a persistent price gap between Korean and global venues. We cover the mechanics in depth in The Upbit Listing Effect & Kimchi Premium Explained.
You can watch Upbit's announcements yourself on the official Upbit notice board. The Seoul endpoint delivers those same events to your trading code as structured JSON, dispatched from within Korea.
Reading Upbit announcements
Upbit publishes several notice categories, and only some are tradable listing events. New KRW or BTC market listings are the headline catalyst, but the notice board also carries market additions for existing tokens, trading-suspension and delisting notices, and investment-caution (유의종목) designations. A caution flag warns of elevated volatility; a caution release can itself be a bullish signal. The endpoint classifies each of these into the shared listingType vocabulary so your bot can branch on the event type rather than parsing Korean-language prose. For a broader comparison of the two big Korean venues, see Bithumb vs Upbit listing strategy.
Choosing your endpoint
Both endpoints speak the same WebSocket protocol and accept the same API key. The choice comes down to where your bot runs and which publishers you follow:
- Bot in Korea, Upbit focus — connect to
wss://kr.cryptolisting.wsfor Upbit, and keep a Tokyo connection only if you also need Binance or Bithumb. - Bot in Tokyo or global, mixed publishers —
wss://cryptolisting.wscarries all three publishers in one stream. - Maximum coverage — run both in parallel (shown above), filtering Tokyo to
?cex=binance,bithumbso Upbit is not duplicated.
Latency, jitter, and co-location
Raw distance is only part of the picture. Two other factors decide how consistently fast an Upbit event reaches your code. The first is jitter — the variation in delivery time from one message to the next. A path that is fast on average but occasionally spikes is harder to build a strategy on than a path that is consistently good, because your worst-case entry is what gets you filled at a bad price. Shorter, simpler network paths tend to have lower jitter, which is a second reason a same-region connection helps beyond the average round-trip.
The second is co-location. Bots that run in AWS Seoul, in the same region as the endpoint, keep the client-to-endpoint leg inside a single datacentre footprint. If your execution venue is also reachable with low latency from Seoul, the whole pipeline — from your socket receiving the event to your order landing — stays geographically compact. The Seoul endpoint exists so that Korea-based operators can build that kind of tight, low-jitter loop for Upbit without the intervening hop to Tokyo.
What stays the same across both regions
The Seoul endpoint is a location change, not a product change. The message schema is identical: the same announcement, heartbeat, and welcome message types, the same listingType vocabulary, and the same microsecond-precision timestamps on every event. Every message carries its own publisher field and timestamps, so a handler written against Tokyo works unchanged against Seoul — you only change the URL. The ?cex=upbit filter is accepted but redundant there, since Seoul dispatches Upbit exclusively. If you already parse the Tokyo feed, migrating is a one-line change. Treat the two connections as a single logical feed with two physical paths.
This article is for informational purposes only and is not financial advice. CryptoListing.ws is a technical data feed service — see Legal.
Related
- The Upbit Listing Effect & Kimchi Premium Explained — why Upbit listing notices produce some of the largest crypto pumps.
- Bithumb vs Upbit: Korean Exchange Listing Notice Strategy — comparing the two largest Korean exchanges and how to monitor both.
- How to Detect New Crypto Listing Announcements in Real-Time — comparison of detection methods.
Try the Seoul endpoint
Same API key, two regions. See our pricing & tiers — free SpeedTrial key available on both endpoints, plus FreeDelayed (full feed, +240 ms).
Get started on Telegram