> ## Documentation index
> Fetch the complete documentation index at: https://docs.predictefy.com/llms.txt
> Use it to discover every available page before exploring further.

# Build on every prediction market

> Unified prediction-market intelligence and execution infrastructure — one normalized API and SDK for all prediction-market builders.

import { Card, CardGrid, LinkButton } from '@astrojs/starlight/components';
import GlyphCard from '../../components/GlyphCard.astro';

export const venues = [
  ['Polymarket', 'polymarket.svg'],
  ['Polymarket US', 'polymarket-us.svg'],
  ['Kalshi', 'kalshi.webp'],
  ['Limitless', 'limitless.svg'],
  ['Hyperliquid', 'hyperliquid.svg', 'hyperliquid-ondark.svg'],
  ['Myriad', 'myriad.svg'],
  ['Opinion', 'opinion.webp'],
  ['Predict.fun', 'predict-fun.svg'],
  ['PRED', 'pred.svg'],
  ['Pascal', 'pascal.svg'],
  ['Rain', 'rain.jpg'],
  ['SX Bet', 'sxbet.svg'],
  ['XO', 'xo.png'],
  ['Gemini', 'gemini.svg'],
  ['PredictStreet', 'predictstreet.png'],
  ['Novig', 'novig.png'],
];

<div class="pf-hero not-content">
  <p class="pf-hero-lead">
    One normalized API and SDK. Change the venue parameter to reach a different venue.
  </p>

  <div class="pf-endpoint">
    <span class="pf-endpoint-method">GET</span>
    <code class="pf-endpoint-path">
      <span class="pf-endpoint-fixed">/api/</span><span class="pf-endpoint-param">{'{exchange}'}</span><span class="pf-endpoint-fixed">/fetchMarkets</span>
    </code>
  </div>

  <p class="pf-endpoint-hint">Swap that one segment for any of the 16 product venues:</p>

  <ul class="pf-venue-wall">
    {venues.map(([name, file, onDark]) => (
      <li class="pf-venue" title={name}>
        {file ? (
          <>
            <img
              class={onDark ? 'pf-venue-onlight' : undefined}
              src={`/venues/${file}`}
              alt={name}
              loading="lazy"
              width="32"
              height="32"
            />
            {onDark && (
              <img class="pf-venue-ondark" src={`/venues/${onDark}`} alt={name} loading="lazy" width="32" height="32" />
            )}
          </>
        ) : (
          <span>Sm</span>
        )}
      </li>
    ))}
  </ul>

  <div class="pf-hero-actions">
    <LinkButton href="/quickstart/">Quickstart</LinkButton>
    <LinkButton href="/api/" variant="minimal">
      API reference
    </LinkButton>
  </div>
</div>

## Pick your path

Three ways in, depending on what you are building.

<CardGrid>
  <Card title="Read market data" icon="magnifier">
    Catalog, prices, and history across venues.

    1. [Quickstart](/quickstart/) — key, first request, pagination
    2. [Venue coverage](/reference/venues/) — what each venue actually supports
    3. [Historical data](/guides/history/) — OHLCV candles and current depth

  </Card>
  <Card title="Build a trading bot" icon="rocket">
    Read with a typed client, then sign and submit your own orders.

    1. [Quickstart](/quickstart/) — key, first request, error envelope
    2. [TypeScript SDK](/guides/sdk/) — the same surface, typed
    3. [Trading &amp; execution](/guides/trading/) — opt-in, client-side signing, venue status

  </Card>
  <Card title="Build an AI agent" icon="puzzle">
    The docs are machine-readable; the API is agent-ready.

    1. [AI agents hub](/guides/agents/) — choose the chat-client or API route
    2. [llms.txt](/llms.txt) — the whole corpus indexed for retrieval
    3. [Agent skill](/.well-known/agent-skills/predictefy/skill.md) — a published, versioned skill

  </Card>
</CardGrid>

## One contract, complete infrastructure

<CardGrid>
  <Card title="Unified market access" icon="database">
    One normalized method family across venues: `fetchMarkets`, `fetchMarket`, `fetchEvents`,
    `fetchSeries`, `fetchOrderBook`, and `fetchTrades`. Swap the `{exchange}` path segment — the
    response shape stays normalized, while unsupported venue/verb combinations fail honestly.
    Markets and events carry `asOf` + `provenance`; markets add `capabilities`. Order books carry
    `asOf` + `provenance` + `sourceMetadata`.
  </Card>
  <Card title="Historical data" icon="clock">
    Cross-venue OHLCV via `fetchOHLCV` (12 resolutions from 1s through 1d, up to 5,000 candles per
    call). Every candle is labeled with its `source` and `quality` — you always know whether you are
    looking at a true venue candle or a point-derived one. Coverage is availability-dependent; no
    uninterrupted
    capture or per-venue freshness guarantee is made. See [Historical data](/guides/history/) for
    the current per-venue depth.
  </Card>
  <Card title="Cross-venue intelligence" icon="random">
    Clusters of equivalent markets matched across venues, plus **indicative price discrepancies**,
    typed market relationships, and executable analysis only when every live-price, depth, fee,
    status, and resolution gate passes. See [Cross-venue intelligence](/guides/cross-venue/).
  </Card>
  <Card title="Trader Intelligence" icon="analytics">
    Venue-scoped trader activity, profiles, leaderboards, versioned scores, and a smart-money feed
    built from public venue-published or on-chain evidence. Unsupported venue concepts stay
    explicitly unsupported. See [Trader Intelligence](/reference/trader-intelligence/).
  </Card>
  <Card title="Execution" icon="padlock">
    Isolated hosted execution and client-side signing for supported venues. The normalized read API
    never receives a builder's private key, and every venue publishes its exact capability and
    custody model. See [Trading](/guides/trading/).
  </Card>
  <Card title="Simple credit pricing" icon="list-format">
    Requests are endpoint-weighted — catalog reads cost 1 credit, live order-book reads 5, history
    5. Sign-up is free: every account starts with 25,000 monthly credits. Trading ships on every
    plan; arbitrage, price-gap, and bulk endpoints start at Builder. See [Credits &amp;
    billing](/guides/credits/).
  </Card>
</CardGrid>

## Every prediction market, one integration

Universal market access is the destination. Today, the normalized data contract covers 16 served
product venues. The table retains the implemented Smarkets contract as a marked dark venue. The
`{exchange}` column is the path segment — swap it to reach a different served venue.

| Venue         | `{exchange}`    | Venue          | `{exchange}`      |
| ------------- | --------------- | -------------- | ----------------- |
| Polymarket    | `polymarket`    | Rain           | `rain`            |
| Polymarket US | `polymarket_us` | PredictFun     | `predictfun`      |
| Kalshi        | `kalshi`        | SX Bet         | `sxbet`           |
| Smarkets (dark)[^smarkets-dark] | `smarkets`      | Pascal         | `pascal`          |
| Opinion       | `opinion`       | XO Market      | `xo`              |
| Hyperliquid   | `hyperliquid`   | PRED           | `pred`            |
| Limitless     | `limitless`     | PredictStreet  | `predictstreet`   |
| Myriad        | `myriad`        | Novig          | `novig`           |
| Gemini        | `gemini`        |                |                   |

A `router` pseudo-exchange unions the list verbs across all served venues.

[^smarkets-dark]: **Dark venue.** Smarkets is implemented but not served on this deployment: every `/api/smarkets/…` request returns
    `404 EXCHANGE_NOT_AVAILABLE`, router fan-outs exclude it, and it is not counted among the served venues. It returns
    when a commercial API agreement is in place.

Execution state differs per venue and changes independently of this page — `GET /v1/exec/venues`
is the live truth. As documented: Pascal, PredictStreet, and XO Market are **armed** isolated
execution lanes; XO advertises build + submit + cancel, PredictStreet has build + submit with no
cancel, and PRED is **darked**, its whole lane unregistered, so even build answers a 404. All four
serve catalog and order books (plus a trades tape on Pascal and PredictStreet), none has a hosted
account lane, and Pascal and PredictStreet have proven venue-history coverage.

The [venue coverage matrix](/reference/venues/) tells you exactly what each venue supports: real
CLOB depth vs. reconstructed books, and which venues expose a public trades tape.

## Built for developers and AI agents

Four clients over one contract, plus a REST surface every one of them speaks.

<CardGrid>
  <GlyphCard title="TypeScript SDK" glyph="typescript">
    Typed client over the normalized contract, with signing kept client-side.
    [TypeScript guide](/guides/sdk/)
  </GlyphCard>
  <GlyphCard title="Python SDK" glyph="python">
    The same surface for research and backtesting workflows.
    [Python guide](/guides/python-sdk/)
  </GlyphCard>
  <GlyphCard title="MCP server" glyph="mcp">
    Thirty-three read, intelligence, and platform tools plus ten guardrailed execution tools,
    all registered by default. [MCP guide](/guides/mcp/)
  </GlyphCard>
  <GlyphCard title="WebSocket API" glyph="websocket">
    Live capability-qualified order-book, trade, and reference-feed streams.
    [Streaming guide](/guides/streaming/)
  </GlyphCard>
</CardGrid>

**REST API** — exchange-style verbs, one error envelope, cursor pagination. The
[API reference](/api/) documents the contract every client above is built on.

**Enterprise SQL** — read-only analytical access over the normalized catalog and
relationship model. Requires a dedicated `sql` scope that no self-serve plan grants;
available on request.

:::note[Universal interface, capability-honest]
One normalized contract does not mean every upstream venue exposes every verb. Books from
venues without a real order book are flagged `synthetic`; missing public trades or trader
identity answer an honest `NOT_SUPPORTED`; execution is exposed only for documented venues;
and cross-venue price gaps remain _indicative_ unless every executable gate passes.
:::