Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.pear.trade/llms.txt

Use this file to discover all available pages before exploring further.

Not available yet. Pear’s public API is still being built. There is no early-access program at the moment. This page exists to lay out what the API will look like so anyone planning to build on Pear can see where we’re headed.

What the API will cover

Pear is a mobile product first. The API will mirror the same surfaces the mobile app uses, exposed as a clean REST + WebSocket interface so external developers can build the same kinds of experiences.

Markets & events

Discover, search, filter, and pull full detail for every market across every venue Pear supports. Event grouping, category filters, and sort metadata are first-class.

Trading

Cost rundowns, route reservations, and execute calls. Same trade flow as the app. Smart routing across venues exposed once it exits beta.

Portfolio

Open positions, realized and unrealized P&L, full trade history, and the same analytics breakdown the in-app Insights tab uses (by category, by venue, over time, win/loss distribution).

Rewards

Cashback summary, full reward-ledger history, milestone progress, and referral status. Read-only on the rewards side, claim flows handled in-app.

Social

Leaderboards, follows, profiles, posts, comments, and the activity feed. Programmatic copytrade once the trading endpoints are stable.

Realtime

WebSocket streams for trade events, market prices, and social activity. Same multiplexed topic model the app uses internally.

Auth

The API will use Bearer token auth, with API keys scoped per integration and per surface (read-only vs. trade-capable). Privy-issued JWTs will continue to work for first-party clients.
"security": [
  {
    "bearerAuth": []
  }
]

What’s not on the roadmap

To set expectations early, a few things the API explicitly will not do at launch:
  • Bypass venue KYC. If a venue requires verification for a market, the API will surface that requirement, not work around it.
  • Custodial trading on behalf of users. Trades execute against the user’s own non-custodial wallets. The API exposes the trade flow, not custody.
  • Backfill arbitrary historical orderbook data. Real-time and recent history will be available; long-tail historical depth is not on the initial scope.

When it ships

When the public API is ready, the full reference (with OpenAPI spec, code samples, and tutorials) will land on this page. Until then, treat this as the planning document.