Home / Blog / Data API

Data API

Real-Time Memecoin Trade Alerts over WebSocket

How to consume the fomoapi.io live alert WebSocket (wss://api.fomoapi.io/ws/alerts) for real-time memecoin trade, thesis, and large-buy/large-sell events, with a reconnecting JS client, the alert JSON shape, and GET /v2/alerts for backfill.

Memecoin trading moves in seconds. By the time a trade shows up in a polling loop that runs every 30 seconds, the price has often already moved. If you are building anything that reacts to what traders are doing on fomo.family, you want a push feed, not a poll. This guide covers the live WebSocket at wss://api.fomoapi.io/ws/alerts, the fields in each alert payload, and how to catch up on anything you missed with GET /v2/alerts.

fomoapi.io is an independent, unofficial API. It captures social-trading activity from the fomo.family app and serves it in a normalized shape. It is not affiliated with fomo.family. Everything below runs against the live free tier at https://api.fomoapi.io with a limit of 60 requests per minute. The WebSocket connection itself does not count against that per-minute limit once it is open, but the initial handshake and any /v2/alerts calls do.

What the alert feed pushes

The WebSocket streams alerts as they happen. Three kinds of events come through the same socket, each tagged by a type field:

  • trade: a tracked trader opened or closed a position on a token.
  • thesis: a trader posted written reasoning about a token, captured alongside the trade context.
  • large-buy and large-sell: a position change above a size threshold, useful for spotting conviction moves without watching every small trade.

Every alert carries a timestamp, a short title, a longer text body, and, where the alert is about a specific token, the token's on-chain address. That last field is what lets you wire alerts into a trade-copying bot or a chart link without a second lookup.

Connecting from JavaScript

Here is a minimal client that opens the socket, handles reconnects, and routes each alert by type. It runs in Node with the ws package, or in a browser with the native WebSocket (drop the import line in that case).

import WebSocket from "ws"; // browser: remove this line, WebSocket is global

const ALERTS_URL = "wss://api.fomoapi.io/ws/alerts";

function connect() {
  const ws = new WebSocket(ALERTS_URL);

  ws.on("open", () => {
    console.log("connected to fomoapi alert feed");
  });

  ws.on("message", (raw) => {
    let alert;
    try {
      alert = JSON.parse(raw.toString());
    } catch (err) {
      console.error("bad payload", err);
      return;
    }
    routeAlert(alert);
  });

  ws.on("close", () => {
    console.log("socket closed, reconnecting in 3s");
    setTimeout(connect, 3000);
  });

  ws.on("error", (err) => {
    console.error("socket error", err.message);
    ws.close();
  });
}

function routeAlert(alert) {
  switch (alert.type) {
    case "large-buy":
    case "large-sell":
      handleLargeTrade(alert);
      break;
    case "trade":
      handleTrade(alert);
      break;
    case "thesis":
      handleThesis(alert);
      break;
    default:
      console.log("unhandled alert", alert.type);
  }
}

function handleLargeTrade(alert) {
  console.log(`[${alert.type}] ${alert.title} -> ${alert.tokenAddress}`);
  // forward to your copy-trade logic, queue, or notifier here
}

function handleTrade(alert) {
  console.log(`[trade] ${alert.title}`);
}

function handleThesis(alert) {
  console.log(`[thesis] ${alert.text}`);
}

connect();

The reconnect logic matters more than it looks. Sockets drop for ordinary reasons: a proxy timeout, a laptop going to sleep, a brief network blip. Without the close handler you would silently stop receiving alerts and not know it. The three-second backoff here is intentionally simple; if you expect frequent drops, add exponential backoff so you are not hammering the endpoint during an outage.

A sample alert payload

Each message is a single JSON object. A large-buy alert looks like this:

{
  "ts": 1756300812,
  "type": "large-buy",
  "title": "cupsey bought PONS",
  "text": "cupsey opened a 4.2 SOL position in PONS at a 1.1M market cap.",
  "tokenAddress": "9wP5Y8xXk3qLd2fN7vHqJ4mR6tZ1sB8cA3eD5uW2gVn"
}

A thesis alert carries the reasoning in text and may still include the token address:

{
  "ts": 1756300955,
  "type": "thesis",
  "title": "cupsey on PONS",
  "text": "Called PONS as a low-float runner. Watching for the 2M cap retest before adding.",
  "tokenAddress": "9wP5Y8xXk3qLd2fN7vHqJ4mR6tZ1sB8cA3eD5uW2gVn"
}

The fields you can rely on across all alert types:

  • ts: Unix timestamp in seconds for when the event was captured.
  • type: one of trade, thesis, large-buy, large-sell.
  • title: a short human-readable line, good for notification titles.
  • text: the fuller description or, for thesis alerts, the written reasoning.
  • tokenAddress: the token's on-chain address, present when the alert is about a specific token. Some feed-level alerts may omit it, so check for its presence before using it.

Catching up with GET /v2/alerts

A WebSocket only delivers what happens while you are connected. When your process restarts, you have a gap. GET /v2/alerts returns recent alert history in the same payload shape, so you can backfill.

curl "https://api.fomoapi.io/v2/alerts?limit=50"
{
  "alerts": [
    {
      "ts": 1756300812,
      "type": "large-buy",
      "title": "cupsey bought PONS",
      "text": "cupsey opened a 4.2 SOL position in PONS at a 1.1M market cap.",
      "tokenAddress": "9wP5Y8xXk3qLd2fN7vHqJ4mR6tZ1sB8cA3eD5uW2gVn"
    },
    {
      "ts": 1756300640,
      "type": "large-sell",
      "title": "orange sold ANSEM",
      "text": "orange closed a 6.0 SOL position in ANSEM near a 3.4M market cap.",
      "tokenAddress": "5tZ1sB8cA3eD5uW2gVn9wP5Y8xXk3qLd2fN7vHqJ4mR"
    }
  ]
}

A practical restart pattern: on startup, call /v2/alerts and process anything with a ts newer than the last one you handled, then open the WebSocket for live events. That closes the gap without double-processing. Store the last ts you acted on so restarts stay idempotent.

Where this fits

A few things people build on this feed:

  • Trade-copying bots. Filter for large-buy on traders you trust, pull tokenAddress, and route it into your execution path. The threshold nature of large-buy alerts keeps you off every tiny scalp.
  • Telegram and Discord alert bots. Map each alert to a message. title becomes the headline, text the body, and tokenAddress becomes a link to your preferred chart or block explorer. Because the payload is already human-readable, the formatting work is light.
  • Live dashboards. Keep a rolling window of recent alerts in memory, render them as they arrive, and use /v2/alerts to seed the view on first load so the dashboard is not empty before the first live event lands.

Rate limits and good behavior

The free tier allows 60 requests per minute across the REST endpoints. The WebSocket is the efficient path for live data because you are not spending request budget on a poll loop; you open one connection and receive events as they occur. Reserve your REST budget for /v2/alerts backfills and lookups. If you run several services, share one socket connection and fan out internally rather than opening a socket per consumer.

The data reflects what was captured from the fomo.family app. Treat it as a signal, not a guarantee: alerts describe observed activity, and any copy-trading logic you build on top should have its own risk controls.

Ship on verified trader data

Both-chain wallets, real PnL, and a realtime feed. One API.

Get an API key

FAQ

How do I receive memecoin trade alerts in real time?
Open a WebSocket connection to wss://api.fomoapi.io/ws/alerts. It pushes trade, thesis, and large-buy/large-sell events as JSON the moment they are captured, so you react without polling. Each message includes ts, type, title, text, and (for token-specific alerts) tokenAddress.
What happens to alerts I miss while my client is disconnected?
The WebSocket only delivers events that occur while you are connected. To backfill a gap, call GET /v2/alerts, which returns recent alert history in the same payload shape. On restart, process anything newer than the last ts you handled, then reconnect the socket.