Search Any FOMO Trader or Token by Name via API

You have a name and you need data. Someone drops a handle in a Telegram chat, or a ticker scrolls past on a feed, and you want the wallet, the PnL, the token address, the market cap. Typing it into a UI does not scale when you are building a bot or a dashboard. This guide covers two search endpoints on fomoapi.io: GET /v2/search, which searches traders and tokens together, and GET /v2/tokens/search, which is token-only. Both are live on the free tier at https://api.fomoapi.io with a limit of 60 requests per minute.

fomoapi.io is an independent, unofficial API that captures social-trading activity from the fomo.family app and serves it in a normalized shape. It is not affiliated with fomo.family.

The unified search: GET /v2/search

GET /v2/search?q= runs one query across both traders and tokens. Each result carries a type field so you can tell them apart in a single response. This is the endpoint you want behind a search box or a chat command where the user could be looking for either.

curl "https://api.fomoapi.io/v2/search?q=cupsey"

{
  "query": "cupsey",
  "results": [
    {
      "type": "trader",
      "handle": "cupsey",
      "wallet": "9wP5Y8xXk3qLd2fN7vHqJ4mR6tZ1sB8cA3eD5uW2gVn",
      "pnlUsd": 184320.55,
      "winRate": 0.61
    },
    {
      "type": "token",
      "symbol": "CUPS",
      "address": "5tZ1sB8cA3eD5uW2gVn9wP5Y8xXk3qLd2fN7vHqJ4mR",
      "name": "Cupsey Coin",
      "marketCapUsd": 742000
    }
  ]
}

Because a single query can return both kinds, always branch on type before you read the rest of the object. A trader result has handle, wallet, and PnL fields; a token result has symbol, address, and marketCapUsd. Reading wallet off a token result, or address off a trader result, will give you nothing.

Narrowing with the type parameter

When you already know what you are looking for, pass type to skip the other category. It accepts traders, tokens, or all (the default).

curl "https://api.fomoapi.io/v2/search?q=cupsey&type=traders"

{
  "query": "cupsey",
  "type": "traders",
  "results": [
    {
      "type": "trader",
      "handle": "cupsey",
      "wallet": "9wP5Y8xXk3qLd2fN7vHqJ4mR6tZ1sB8cA3eD5uW2gVn",
      "pnlUsd": 184320.55,
      "winRate": 0.61
    }
  ]
}

Scoping the query to traders keeps token matches out of the response, which is what you want behind a "find a trader" command. It also keeps the payload smaller when a common string would otherwise match a lot of tokens.

Resolving a handle to a wallet and PnL

The most common trader lookup is: I have a handle, give me the wallet and how they have done. The search result already includes both, and if you want the full trader record you can follow up with GET /v2/users/{handle}.

curl "https://api.fomoapi.io/v2/users/cupsey"

{
  "handle": "cupsey",
  "wallet": "9wP5Y8xXk3qLd2fN7vHqJ4mR6tZ1sB8cA3eD5uW2gVn",
  "pnlUsd": 184320.55,
  "realizedPnlUsd": 152100.00,
  "unrealizedPnlUsd": 32220.55,
  "winRate": 0.61,
  "tradeCount": 428
}

The pattern is: search to resolve an ambiguous name into a concrete handle and wallet, then call /v2/users/{handle} when you need the fuller breakdown. If you already have the exact handle, you can skip search and go straight to the user endpoint.

Token-only search: GET /v2/tokens/search

GET /v2/tokens/search?q= matches on token symbol or name and returns token records only. Reach for it when the input is unambiguously a ticker and you do not want trader results in the way.

curl "https://api.fomoapi.io/v2/tokens/search?q=PONS"

{
  "query": "PONS",
  "results": [
    {
      "symbol": "PONS",
      "address": "9wP5Y8xXk3qLd2fN7vHqJ4mR6tZ1sB8cA3eD5uW2gVn",
      "name": "Pons",
      "marketCapUsd": 1120000
    }
  ]
}

It also matches on name, so a query like ANSEM resolves the same way:

curl "https://api.fomoapi.io/v2/tokens/search?q=ANSEM"

{
  "query": "ANSEM",
  "results": [
    {
      "symbol": "ANSEM",
      "address": "5tZ1sB8cA3eD5uW2gVn9wP5Y8xXk3qLd2fN7vHqJ4mR",
      "name": "Ansem",
      "marketCapUsd": 3400000
    }
  ]
}

Each token record gives you symbol, address, name, and marketCapUsd. The address is the field that matters most downstream: it is what you hand to a chart, a block explorer, or your own on-chain lookups. Short tickers can collide, so when you get multiple results, use marketCapUsd and name to pick the one you meant rather than assuming the first row is correct.

Which endpoint to use

• A search box or chat command where input could be anything. Use /v2/search. Branch on type to render traders and tokens differently.
• A "find a trader" flow. Use /v2/search?q=...&type=traders, then /v2/users/{handle} for the full record.
• A ticker lookup. Use /v2/tokens/search. It skips traders entirely and returns the address and market cap you need.

The two search endpoints overlap on purpose. /v2/search is the general front door, and /v2/tokens/search is the specialized path for when you already know the input is a token. Using the narrow endpoint when you can keeps responses smaller and removes an entire class of false matches, since a trader named after a coin will not surface in a token-only search.

Handling matches in code

A small helper that resolves a name to whatever it is:

async function resolve(name) {
  const res = await fetch(
    `https://api.fomoapi.io/v2/search?q=${encodeURIComponent(name)}`
  );
  const data = await res.json();
  const traders = data.results.filter((r) => r.type === "trader");
  const tokens = data.results.filter((r) => r.type === "token");
  return { traders, tokens };
}

Always encodeURIComponent the query. Handles and token names can contain characters that break a raw URL, and skipping the encode is a common source of empty results that look like the endpoint is down when it is really a malformed request.

Rate limits

Both endpoints share the free tier limit of 60 requests per minute. If you are resolving a batch of names, space the calls or cache what you have already resolved; addresses and handles do not change, so a resolved name is safe to cache for a long time. PnL and market cap move, so re-fetch those on the interval that fits your use case rather than caching them indefinitely.

The data reflects what was captured from the fomo.family app. Treat market cap and PnL figures as recent snapshots for analysis, not as live quotes.