Predict.fun API: what it exposes, how it authenticates, where it stops

What the API exposes

REST endpoints cover categories and tags, markets (detail, statistics, last sale, orderbook, timeseries), orders (create LIMIT or MARKET, get by hash, list, match events, remove by hash or in bulk), positions by wallet, account activity, referral codes and full-text search across categories and markets.

The WebSocket at wss://ws.predict.fun/ws streams one topic per subscription. Market topics are predictOrderbook/{marketId} with aggregated levels, predictTradingStatus (OPEN, MATCHING_NOT_ENABLED, CANCEL_ONLY, CLOSED), predictMarketStatus with outcome prices, and predictMarketChanged for cache invalidation. Wallet events require a JWT in the topic string.

The server sends a heartbeat every 15 seconds that the client must echo; a missed heartbeat closes the connection.

Authentication and rate limits

Two credentials. An API key (header x-api-key) is required for every mainnet endpoint and for the WebSocket handshake. A JWT is required for personal operations: call GET /v1/auth/message, sign the message with your wallet, and POST /v1/auth to receive the token.

Smart-wallet users sign with the SDK's signPredictAccountMessage using the Privy wallet private key exported from account settings, and the docs recommend funding that wallet with BNB for approvals and cancels.

The default rate limit is 240 requests per minute per API key on mainnet, and 240 per minute without a key on testnet. Each key carries its own limits on the WebSocket too.

Pricing and access

API keys are requested through the developer console at developers.predict.fun. No price for access is listed.

SDKs: @predictdotfun/sdk on npm and predict-sdk on PyPI, with source under the PredictDotFun GitHub organization. Both SDKs are also published to Context7 for AI-assisted lookup. Primary servers sit in ap-northeast-1.

Where it falls short

The REST API is in beta and the FAQ asks you to report issues in Discord rather than through a status page.

Trading fees are absent from the developer docs, so fee modelling needs the product side of the site.

240 requests per minute is four per second, and the auth flow for smart accounts needs a private-key export plus BNB for gas.

Who should use it

Builders who want a full testnet to rehearse order flow before touching mainnet, and BNB Chain traders who want typed SDKs.

High-frequency strategies will hit the per-minute ceiling quickly and should lean on the WebSocket snapshots instead of polling.