What Is a Social Trading Data API?

A social trading data API lets software ask questions about named traders instead of starting with anonymous wallet addresses. It connects a social profile to the data a product needs: resolved wallets, FOMO-reported performance, positions, holdings, theses, leaderboards, and realtime feed events.

The useful distinction is identity plus activity. A blockchain RPC can return transactions for an address, but it does not know which FOMO handle a user typed. A social trading API resolves that handle first, then exposes the product data available for the resolved account.

This page uses FOMO API as the concrete example. The FOMO API reference and its OpenAPI file are the source of truth for current routes and response fields.

The five data layers

A practical social trading integration usually combines five layers:

1. Identity: resolve a handle to a profile, a stable user identifier, and available Solana and EVM wallets.
2. Performance: read the PnL windows, volume, trade count, and leaderboard data reported for that account.
3. Portfolio: fetch current balances and the positions currently available through FOMO.
4. Context: read theses, followers, account age, and other social fields when the product needs them.
5. Events: subscribe to feed or on-chain streams when polling REST would be too slow or wasteful.

Those layers should remain separate in your data model. A display handle can change. A wallet can be missing while resolution is in progress. A position-history response can be partial. Treat each as explicit state instead of collapsing everything into one supposedly complete trader record.

Start with identity resolution

The first request for a FOMO integration is normally GET /v2/users/{handle}. It accepts a handle and returns the normalized profile plus the wallets and statistics currently associated with it.

curl "https://api.fomoapi.io/v2/users/frankdegods" \
  -H "Authorization: Bearer $FOMO_API_KEY"

Read only the fields your application needs, and validate them before persistence. A wallet can be null. That is not permission to substitute an address from a different profile or an unverified third-party list.

For a complete server-side example, use the Python quickstart or the TypeScript guide linked from it.

Add portfolio and position data

Two user-scoped routes answer different questions:

Do not market the positions response as a complete lifetime ledger. The response can expose coverage fields such as partial and complete, and deeper reads can require additional upstream work. If a tax, compliance, or accounting workflow requires exhaustive chain history, resolve the wallets and use the appropriate chain data source.

This boundary matters for user trust. A missing historical position and a zero-value position are not the same fact.

Use leaderboards for discovery, not proof

The leaderboard route, GET /v2/leaderboard/{window}, ranks the data reported for supported windows. It is useful for discovery pages and for selecting traders to inspect further.

A leaderboard is not a promise that the first row is universally the best trader. Products should show the ranking window, relevant metrics, and any coverage limitations. Avoid turning one PnL number into an investment recommendation.

Choose the correct realtime stream

FOMO API exposes two different WebSocket products:

• /ws/alerts mirrors the FOMO app feed and includes alert, thesis, and push-derived activity. It is available across plans with different delivery timing.
• /ws/trades is the separate on-chain trade stream for eligible plans. Its access rules and message shape differ from the app-feed stream.

Do not write one parser and assume the streams are interchangeable. A production client should process the welcome frame, monitor application heartbeats, deduplicate replayed event IDs, and reconnect with bounded backoff. The production WebSocket guide implements those controls.

For recent app-feed activity without a persistent socket, GET /v2/alerts provides a REST fallback. Its available history is bounded, so it is a recovery aid rather than a permanent event archive.

What developers build

The data can support several product types without changing its meaning:

• a trader research page that resolves a handle and displays the available performance windows;
• a portfolio view that combines balances with position coverage state;
• a notification service that filters app-feed events by trader, token, chain, or alert type;
• a research workflow that joins theses to the account and token they discuss;
• an internal watchlist that stores stable user and event IDs rather than relying on display names.

Copy-trading is also possible as an application, but the API event should be treated as input to a separate risk and execution system. A feed message is not a recommendation, fill guarantee, or instruction to trade.

How to evaluate a social trading API

Before choosing an integration, test the contract rather than the marketing page:

1. Confirm that every documented route is present in a machine-readable API specification.
2. Check how authentication, credits, and rate limits are reported.
3. Test null, missing, partial, and retryable responses.
4. Determine whether a stream is an app feed, an on-chain feed, or another source.
5. Verify the stable identifiers available for deduplication and database joins.
6. Check whether historical coverage is bounded.
7. Keep API keys out of browser bundles and logs.
8. Measure latency and completeness for your own workload instead of relying on an undated benchmark.

Current allowances and stream eligibility belong on /pricing, not frozen inside an evergreen explainer. Create a server-side key in the dashboard, then build against the documented fields your product actually uses.

That is the core of a social trading data API: resolve the person, retrieve the available account data, preserve uncertainty, and use stable identities to connect current state with new events.