Get outcome
Path parameters
Response
Human-readable label. Backend-generated for sports; caller-supplied otherwise. Always present and non-empty.
Hyperliquid identifiers, null until the market is deployed.
Wrapper types rather than plain int64, and deliberately not optional int64:
proto3 optional is a synthetic oneof, which EmitUnpopulated skips, so an
unset field would vanish from the response instead of being null. Every key
is always present — a null one is spelled null.
The validator-approved template this market instantiates.
A map has no wrapper type, and needs none: an outcome with no template has no keywords either, and an empty object says that unambiguously.
How it settled on chain, as a decimal string: “1” pays side 0 in full, “0” pays side 1, anything between splits. Null until Hyperliquid confirms. Compare it as a decimal — the chain reports “0” back as “0.0”.
The question this outcome belongs to. Null on a standalone market. Several outcomes of one event share one question_id.
Predict-approved payout, both sides, empty until settlement_approved_at.
Chain-confirmed payout, both sides, empty until settled_at.
The two Hyperliquid tokens, ordered side 0 then side 1. Always length 2. A participant’s name and abbreviation are joined live; token names without a participant (Up/Down, No) are stored on the row.
Order constraints a client needs to construct a Hyperliquid order without reading /info. Always present, including on drafts: HIP-4’s defaults are known before deploy, and deploy overwrites them from the chain.
Identities this market is known by at external data providers. Fixture and event ids stay on the event; market ids (a Polymarket token, a Kalshi ticker) live here. Empty until linked.
This instrument is about that team. Set on a soccer home/away leg; unset on a two-way moneyline and on draw. The event already renders the team.