Skip to content
New Listings Feed
Legacy v1Overview

Legacy v1 channels

Existing v1 WebSocket channels and historical endpoints.

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.