> Use the canonical URL for citations. For the complete Predict API documentation index, fetch https://docs.staging.trypredict.com/llms.txt.

# How Predict and Hyperliquid work together

> Understand which API owns catalog metadata, market data, order entry, balances, fills, settlement, and real-time streams when trading Predict outcomes.

Predict and Hyperliquid serve different parts of the trading workflow:

| Need                                                            | Source                                           |
| --------------------------------------------------------------- | ------------------------------------------------ |
| Events, outcomes, labels, questions, and lifecycle              | Predict REST API                                 |
| Normalized prices, trades, holders, statistics, and charts      | Predict REST or realtime API                     |
| Normalized positions, open orders, activity, PnL, and fees      | Predict REST or realtime API                     |
| Full books, venue mids, and candles                             | Hyperliquid `/info` or `/ws`                     |
| Place, modify, or cancel orders                                 | Predict REST API, `/v1/trading/*`                |
| Venue-native balances, order state, history, and limits         | Hyperliquid `/info` or account WebSocket streams |
| Approving an agent wallet, builder fees, transfers, withdrawals | Signed Hyperliquid action, sent to Hyperliquid   |
| Split, merge, and negate balance-conversion operations          | Predict REST API, `/v1/trading/*`                |

Predict is the only documented source for outcome and question data. Do not discover, label, or reconcile outcomes from Hyperliquid metadata.

Predict serves order entry at `/v1/trading/*`. You still sign the Hyperliquid action yourself, with your own key, exactly as you would to send it to the venue — Predict forwards the signed envelope byte for byte and answers with Hyperliquid's own reply. It never holds a key, never signs on your behalf, and stores nothing about the write.

Two things follow from that. The request body is Hyperliquid's, not Predict's: `a`, `b`, `p`, `s`, and the rest keep the venue's names rather than this API's snake_case, because the signature covers those exact bytes and any rewrite would invalidate it. And the surface is HIP-4 order entry only — approving an agent, approving a builder fee, transferring, and withdrawing are not proxied and still go to Hyperliquid directly.

What you gain is one host, one set of rate limits, and a stable egress: Predict spreads requests over a pool of source addresses it owns, so your throughput is not shared with everyone else on your NAT.

## Environments

Use one environment consistently from discovery through execution.

| Predict REST                         | Predict realtime                         | Hyperliquid HTTP                      | Hyperliquid WebSocket                  |
| ------------------------------------ | ---------------------------------------- | ------------------------------------- | -------------------------------------- |
| `https://api.staging.trypredict.com` | `wss://api.staging.trypredict.com/v1/ws` | `https://api.hyperliquid-testnet.xyz` | `wss://api.hyperliquid-testnet.xyz/ws` |

The direct-trading reference lists testnet before mainnet. Predict staging outcomes belong to Hyperliquid testnet; mixing a staging `hl_id` with mainnet can address an unrelated asset or return no data.

## Recommended flow

1. List active Predict outcomes and keep their labels and Hyperliquid identifiers.
2. Convert the selected outcome side to its coin and exchange asset ID.
3. Subscribe to normalized Predict updates and read the full book or venue balance from Hyperliquid testnet when needed.
4. Create a unique client order ID, sign the action in a trusted environment, and POST the signed envelope to `/v1/trading/orders`.
5. Inspect every action status, then reconcile through order and fill reads or WebSocket updates.

Continue with [market identifiers](/guides/direct-trading/market-identifiers) before constructing a request.