Every v1 channel is a WebSocket stream. The five paid channels also provide a historical REST API at the same path. The channel determines the payload shape. See Legacy v1 schemas.
| Channel | Path | Keys | What it carries |
|---|---|---|---|
| Feed | /v1/feed |
FREE | Aggregated listings and delistings with compact payloads. |
| New listings | /v1/new-listings |
STARTER, PRO | Parsed listing events with detected tickers. |
| Delistings | /v1/delistings |
STARTER, PRO | Parsed delisting events, including caution notices. |
| Announcements | /v1/announcements |
STARTER, PRO | Raw exchange notices, pushed before parsing. |
| Enhanced listings | /v1/new-listings-enhanced |
STARTER, PRO | Listings with contracts, DEX pairs, and metrics. Beta, Tokyo only. |
| Enhanced delistings | /v1/delistings-enhanced |
STARTER, PRO | Delistings with the same enrichment. Beta, Tokyo only. |
Endpoints by region
Base hosts per region. Append the channel path to build the full URL.
| Host | Used by | Paths |
|---|---|---|
tokyo.newlistings.pro |
STARTER, PRO | /v1/announcements, /v1/new-listings, /v1/delistings, /v1/new-listings-enhanced, /v1/delistings-enhanced |
ny.newlistings.pro |
STARTER, PRO | /v1/announcements, /v1/new-listings, /v1/delistings |
ws.newlistings.pro |
FREE | /v1/feed |
The free feed is stream-only. The five v1 paid channels support history at the same path.
Connect to v1
Send your key in the Authorization: Bearer header when opening the WebSocket:
wscat -H "authorization: Bearer YOUR_KEY" \
-c wss://tokyo.newlistings.pro/v1/new-listings
Choose an endpoint from the table above for your plan. FREE keys connect to wss://ws.newlistings.pro/v1/feed.
Connection greeting
A PRO connection to the Tokyo listing channel sends this greeting:
{
"type": "success",
"message": "Connection established successfully. Streaming started.",
"channel": "new-listings",
"delay": "0ms",
"instance": "Tokyo"
}
channel identifies your stream, and delay reports the applied delay. instance is omitted on ws.newlistings.pro. Legacy v1 has no READY code or subscription object. An event can arrive before the greeting, so handle both independently.
Node.js example
Save as legacy-client.cjs and set NLF_KEY in your environment. This example stops after disconnection; it does not retry automatically.
// npm install [email protected]
const WebSocket = require("ws");
const key = process.env.NLF_KEY;
if (!key) throw new Error("Set NLF_KEY before starting the client.");
const ws = new WebSocket("wss://tokyo.newlistings.pro/v1/new-listings", {
headers: { authorization: `Bearer ${key}` },
handshakeTimeout: 10000,
});
ws.on("message", (data) => {
let message;
try {
message = JSON.parse(data.toString());
if (!message || typeof message !== "object" || Array.isArray(message)) {
throw new Error("Expected a JSON object");
}
} catch (error) {
console.error("Invalid message:", error.message);
ws.close();
return;
}
if (message.type === "success") {
console.log("connected", message.channel, message.delay);
} else if (message.type === "error") {
console.error(message);
ws.close();
} else {
// Handle the event according to the selected v1 channel's schema.
console.log(message);
}
});
ws.on("error", (error) => console.error(error.message));
ws.on("close", (code, reason) => console.log("closed", code, reason.toString()));
V1 listings use a product type such as spot, and raw announcements have no type. Do not apply the v2 announcement/tweet event filter to these messages.
Errors and reconnects
Rejected v1 WebSocket upgrades return an HTTP status and plain-text body. They do not use the v2 JSON error codes.
| HTTP status | What to do |
|---|---|
400 |
Correct the host or request before retrying. |
401 |
Check the key, expiry, plan, region, channel, and distinct-IP allowance before retrying. |
429 |
Honor Retry-After when present. If the body says the active connection limit was exceeded, close another socket before retrying. |
503 |
Authentication is temporarily unavailable. Retry with backoff and honor Retry-After when present. |
For transient disconnects, retry with backoff starting at 1 second and doubling up to 30 seconds, with random jitter. A Retry-After value takes priority even when it exceeds that cap. Repeated failed authentication can lead to a temporary IP ban.
Pause retries for WebSocket close codes 1008, 4001, or 4404. Read the close reason and correct access or client behavior. 4001 can indicate expired, revoked, or changed key access. A close with 1011 indicates an internal failure and can be retried with backoff. Always handle the close event; a JSON error is not guaranteed.
Answer protocol pings with pongs, which ws handles automatically. Do not send JSON heartbeats or other application messages. Repeated unexpected messages can close the socket.
Reconnecting resumes live events. Use the separate v1 historical API to backfill paid channels.
Request and connection limits
These are the default limits at each serving v1 process. All applicable limits must be satisfied; the per-key and per-IP budgets do not replace each other.
| Limit | Budget |
|---|---|
| History requests per known key | 120 per 60 seconds |
| WebSocket attempts per known key | 300 per 60 seconds |
| WebSocket attempts per IP | 50 per 10 minutes and 200 per hour |
| Unknown-key attempts per IP | 20 per 60 seconds |
| Active sockets per key and IP | 6 across the v1 channels on that process |
Your key also has a distinct-IP allowance, listed under Keys. The v2 limits are different.