Data API
FOMO Wallet Data: Pull Holdings, PnL & Trades via API
This guide shows how to pull holdings, PnL, and trade history from any social trader's wallet using fomoapi.io. You'll see real request/response shapes, multi-chain coverage (Solana + EVM), and how verified on-chain data differs from self-reported metrics.
A FOMO wallet data API connects social trader handles to on-chain wallets, letting you pull verified holdings, PnL, and trade history without scraping or guessing. If you're building a leaderboard, copy-trading bot, or analytics dashboard, you need real wallet addresses and real transaction data. This guide walks through the endpoints that surface that data, the tradeoffs of multi-chain coverage, and the rate limits you'll hit.
What is FOMO wallet data?
FOMO wallet data ties a trader's social identity (their Twitter or Telegram handle) to the actual wallets they trade from. Instead of self-reported performance screenshots, you get:
- Verified PnL: calculated from real on-chain trades, not user input.
- Live holdings: token balances across Solana and EVM chains, refreshed in near-realtime.
- Full trade history: every swap, buy, and sell, with timestamps, amounts, and token addresses.
- Cross-chain resolution: one handle maps to multiple wallets (a Solana address, an Ethereum address, etc.), so you see the complete picture.
The data comes from blockchain state and transaction logs. A trader can't fake a 300% return or hide a losing streak because the API reads directly from the chain. This matters when you're routing real money based on someone's track record.
Why verified wallet data matters
Self-reported PnL is trivial to game. A trader posts a screenshot of a winning position, crops out the losses, or cherry-picks a timeframe. When you query a FOMO wallet data API, you're reading the same immutable ledger that settled those trades. If a wallet shows $12,000 profit over 30 days, you can trace every transaction that contributed to that number.
Three reasons this verification layer is critical:
- Trust: users of your leaderboard or copy-trading tool need confidence that the numbers are real.
- Compliance: some jurisdictions or platforms require auditable track records.
- Signal quality: if you're building algo strategies that follow top traders, garbage data means garbage alpha.
The alternative is manual wallet tracking (slow, error-prone) or trusting third-party aggregators that may mix verified and unverified sources. A dedicated API gives you one source of truth with consistent data models.
GET /v2/users/{id}/balances: Pull current holdings
This endpoint returns every token a trader currently holds, denominated in both native units and USD. You pass a user ID (resolved from their handle via /v2/users/{handle}) and get back an array of balances.
Request:
GET https://api.fomoapi.io/v2/users/abc123/balances
Authorization: Bearer YOUR_API_KEY
Response shape (simplified):
{
"user_id": "abc123",
"balances": [
{
"chain": "solana",
"token_address": "So11111111111111111111111111111111111111112",
"symbol": "SOL",
"amount": "42.5",
"usd_value": 8925.00
},
{
"chain": "ethereum",
"token_address": "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2",
"symbol": "WETH",
"amount": "1.2",
"usd_value": 3840.00
}
],
"total_usd": 12765.00,
"updated_at": "2025-01-15T10:32:00Z"
}
What you get:
- Token address, symbol, and raw amount.
- USD valuation at the time of the query.
- Total portfolio value across all chains.
- Timestamp so you know data freshness.
Use case: You're building a "who holds what" dashboard. A user searches for a meme coin address, and you show which top traders hold it, along with position size. You call /balances for each trader ID, filter by token_address, and rank by amount.
Latency is typically under 200ms for cached balances, but can spike to 1-2 seconds if the API needs to refresh on-chain state. If you need sub-second updates, consider the WebSocket feed (covered in the full list of API endpoints).
GET /v2/users/{handle}: Fetch PnL and performance
This endpoint resolves a social handle (e.g., @cryptotrader) to a user profile that includes:
- Total realized PnL over configurable windows (7d, 30d, 90d, all-time).
- Win rate, average trade size, and number of trades.
- Wallet addresses for every supported chain.
- Leaderboard rank (if the trader is in the top cohort).
Request:
GET https://api.fomoapi.io/v2/users/@cryptotrader
Authorization: Bearer YOUR_API_KEY
Response excerpt:
{
"user_id": "xyz789",
"handle": "@cryptotrader",
"wallets": {
"solana": "7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAsU",
"ethereum": "0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb"
},
"pnl_30d": 14250.00,
"win_rate_30d": 0.68,
"trades_30d": 87,
"rank_30d": 42,
"updated_at": "2025-01-15T10:30:00Z"
}
Key fields:
pnl_30d: realized profit/loss in USD over the last 30 days.win_rate_30d: fraction of profitable trades (0.68 = 68%).trades_30d: total number of trades executed.rank_30d: position on the live trader leaderboard for that window.
Why this matters: You can gate access to your copy-trading bot based on win_rate_30d > 0.6 or pnl_30d > 10000. You can also display a trader's rank badge in your UI without maintaining your own leaderboard logic.
PnL is recalculated every few minutes, so if a trader closes a big position, you'll see the updated number within that window. For tick-by-tick updates, use the WebSocket endpoint.
GET /trades?user=: Retrieve full trade history
This endpoint returns every swap, buy, and sell a trader has executed, paginated and sorted by timestamp. You can filter by date range, token, or chain.
Request:
GET https://api.fomoapi.io/trades?user=xyz789&start_date=2025-01-01&limit=50
Authorization: Bearer YOUR_API_KEY
Response (one trade):
{
"trade_id": "tx_abc123",
"user_id": "xyz789",
"timestamp": "2025-01-10T14:22:00Z",
"chain": "solana",
"type": "buy",
"token_in": {
"address": "So11111111111111111111111111111111111111112",
"symbol": "SOL",
"amount": "5.0"
},
"token_out": {
"address": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
"symbol": "USDC",
"amount": "1050.00"
},
"usd_value": 1050.00,
"pnl": null,
"tx_hash": "5Kn7..."
}
What you can do with this:
- Backtesting: replay a trader's strategy against historical price data to see if their alpha holds.
- Attribution: break down PnL by token or time period to understand what drove returns.
- Alerts: trigger notifications when a followed trader buys a specific token.
Pagination is cursor-based. The response includes a next_cursor field; pass it in the next request to fetch the next page. Default limit is 50 trades per call, max is 500.
Performance note: Fetching 10,000 trades for a high-frequency trader will take multiple requests. If you need bulk historical data, reach out via t.me/eulatxt to discuss a data export or higher rate limits.
Multi-chain coverage: Solana + EVM
The API tracks wallets on six chains:
| Chain | Type | Use case |
|---|---|---|
| Solana | L1 | Meme coins, DeFi, NFT trading |
| Ethereum | EVM L1 | Blue-chip DeFi, stablecoins |
| Base | EVM L2 | Low-fee onchain apps |
| BSC | EVM L1 | High-frequency trading, gaming |
| Arbitrum | EVM L2 | DeFi derivatives, leverage |
| Polygon | EVM L2 | NFTs, gaming, low-cost txns |
When you query /v2/users/{handle}, you get wallet addresses for all supported chains. This means a single trader ID gives you:
- Their Solana address (for SPL tokens and Raydium swaps).
- Their Ethereum address (for ERC-20s and Uniswap trades).
- Their Base, BSC, Arbitrum, and Polygon addresses if they trade there.
Why this matters: A trader might ape into a Solana meme coin, take profit in USDC, bridge to Ethereum, and deploy into a yield vault. If you only track one chain, you miss half the story. Multi-chain coverage lets you calculate true net PnL and see the full portfolio.
Caveat: Not every trader uses every chain. If a trader has never touched Base, their Base wallet address will be null or show zero activity. The API does not invent addresses; it only returns what it can verify.
Rate limits and pricing
The free tier (no API key required) is rate-limited to 10 requests per minute. This is enough to prototype or build a personal dashboard, but you'll hit the ceiling quickly if you're polling a leaderboard of 50 traders every 30 seconds.
Paid tiers (from the API pricing tiers page):
| Plan | Price/mo | Rate limit | Use case |
|---|---|---|---|
| Starter | $99 | 1,000 req/min | Small dashboards, personal bots |
| Pro | $399 | 5,000 req/min | Production apps, copy-trading tools |
| Scale | $1,200 | 20,000 req/min | High-frequency bots, analytics SaaS |
WebSocket feed: Included in all paid plans. You subscribe to a user ID or token address and receive realtime trade events as they happen. This bypasses the need to poll /trades every few seconds and reduces your request count.
Overage: If you exceed your plan's rate limit, requests return HTTP 429. No automatic overage billing. Upgrade your plan or wait for the rate limit window to reset (1 minute).
Caching strategy: If you're displaying leaderboard data that doesn't need to be tick-perfect, cache responses for 60 seconds. This cuts your request volume by 60x and keeps you under the free tier for small projects.
Example use cases
1. Copy-trading bot
You maintain a whitelist of 20 top traders. Every 10 seconds, you call /v2/users/{id}/balances for each to detect new positions. When a trader buys a token you don't hold, your bot mirrors the trade on your own wallet. You use /trades?user= to backtest each trader's strategy before adding them to the whitelist.
2. Social leaderboard
You run a website that ranks crypto traders by 30-day PnL. You call /v2/leaderboard/30d once per minute to get the top 100, then call /v2/users/{id} for each to fetch profile details (handle, avatar, wallet addresses). Users can click a trader to see full trade history via /trades?user=.
3. Token holder graph
You're analyzing a new meme coin. You call /token/{address}/holders to see which wallets hold it, then cross-reference those wallet addresses with /v2/users/{id} to identify known traders. This tells you if the token is held by proven alpha generators or just random wallets.
4. Risk dashboard
You're managing a fund that follows 10 external traders. You call /v2/users/{id}/balances every hour to monitor concentration risk (e.g., "Trader A has 80% of their portfolio in one token"). If a trader's pnl_7d drops below a threshold, you reduce your allocation to their strategy.
Each of these scenarios requires verified wallet data. Self-reported PnL or scraped Twitter screenshots won't cut it when you're routing capital.
Closing
Building on top of social trading data means trusting the source. fomoapi.io resolves handles to verified wallets and serves PnL, holdings, and trades through REST and WebSocket endpoints. You get multi-chain coverage, ranked leaderboards, and realtime feeds without running your own indexer. Grab a key at t.me/eulatxt or start with the free tier at https://fomoapi.io/.
Ship on verified trader data
Both-chain wallets, real PnL, and a realtime feed. One API.
Get an API key