> ## Documentation Index
> Fetch the complete documentation index at: https://docs.parlayx.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Welcome to ParlayX

> Institutional infrastructure for prediction markets.

Prediction market venues are built for individual accounts. One login, one balance, one set of keys, no way to say who on your team may do what. That works until more than one person is trading, or until capital needs to be kept apart.

ParlayX sits above the venues and supplies the layer they do not have: segregated books of capital, per-trader access control, key and credential management, and a single unified view of positions across every venue you trade.

You keep custody. ParlayX cannot move your funds, close your positions, or trade on your behalf.

## What ParlayX gives you

<CardGroup cols={2}>
  <Card title="Pods" icon="folder-tree" href="/pods">
    Segregated books of capital. Separate balances, separate access, separate performance.
  </Card>

  <Card title="Actors and Permissions" icon="user-lock" href="/actors-and-permissions">
    Traders and bots, each with their own credential, scoped to one pod, revocable instantly.
  </Card>

  <Card title="Custody and Key Management" icon="key" href="/custody-and-key-management">
    You hold the keys. Regulated venue accounts stay yours; our access there is trading-only.
  </Card>

  <Card title="Cross-Venue Execution" icon="arrows-split-up-and-left" href="/venues">
    Kalshi and Polymarket execution through one integration.
  </Card>

  <Card title="Market Mappings" icon="link" href="/market-mappings">
    The same outcome, aligned across every venue that lists it. Deterministic, not inferred.
  </Card>

  <Card title="Portfolio Visibility" icon="chart-mixed" href="/portfolio-and-positions">
    Orders, fills, positions, and per-market risk across all pods and actors in one view.
  </Card>
</CardGroup>

## Who uses it

* **Funds and trading desks** running several strategies, or several traders, out of one venue relationship.
* **Market makers** quoting the same events across venues who need one consistent identifier per outcome.
* **Hedging and insurance desks** placing risk on prediction markets alongside traditional markets, who need each client book kept apart.
* **Individual traders** running multiple systematic strategies who want each one funded and measured separately.

## How to read these docs

This section is the conceptual overview: what the objects are and how they fit together. It is the right place to start whether you will use the console, the API, or both.

The **API Reference**, **WebSocket API**, and **SDK** tabs are the technical surface. Nothing there contradicts what is described here; it is the same model expressed in endpoints.

To get set up, see the [Getting Started](/getting-started) guide.