# How to read a market's rules from the API before you trade it

Where the settlement source, the cutoff and the fallback clause actually live in five prediction-market APIs — on the series or the event, rarely on the market.

*https://predictionmarkets.tools/how-to/read-a-markets-rules-from-the-api · next to Prediction Market Data APIs*

**Answer:** Every venue publishes the rules before it resolves, and none of them put them in the title. Kalshi carries settlement sources and links to the filed contract terms as fields on the series; Polymarket ships the rules text on the market record; Limitless names an oracle per market type. Read the series or the event, not only the market, and read it before you take a position rather than after the outcome you disagree with.

## The approaches, in order

1. [Kalshi API](https://predictionmarkets.tools/tools/kalshi-api.md) — The only surface here that publishes the chain as fields — a settlement_sources array plus links to the terms filed with the CFTC, readable with no account.
2. [Polymarket Gamma API](https://predictionmarkets.tools/tools/polymarket-gamma-api.md) — The rules text arrives as a block of prose on the market record, beside the condition id and the outcome token ids. Keyless, and where the fallback is written.
3. [Limitless API](https://predictionmarkets.tools/tools/limitless-api.md) — A venue where the resolver differs by market type — a price oracle, a time-weighted average, or the team — and misresolution refunds the stake, not the dollar.
4. [Futuur API](https://predictionmarkets.tools/tools/futuur-api.md) — An OpenAPI schema with status, resolution and resolve_date as fields and no resolution_source at all; the source is a sentence inside the event description.
5. [Predictefy](https://predictionmarkets.tools/tools/predictefy.md) — The cross-venue version of the question, scoring two venues' published rules against each other — and nothing at all is readable without a key.

*Ordered editorially. Paid placement does not affect this order.*

## The short way

Fetch the market, then fetch the thing above it. On every venue here the tradeable object is the
smallest one in the hierarchy, and the rules that decide it are attached one or two levels up — to
the event, or to the series the event repeats under. A market record answers with a ticker, a
price and a close time, and not one of those is the rule.

[The Kalshi API](https://predictionmarkets.tools/tools/kalshi-api) is the only surface in this catalogue that publishes the whole
chain as data. Each series record carries a `settlement_sources` array — each entry a name and a
URL — plus a `contract_url` and a `contract_terms_url` pointing at the terms the exchange filed
with the CFTC, where product self-certifications by a designated contract market are public
documents. Walk up, and stop at the series:

```text
market   what you trade: ticker, price, close time
  |
event    the occasion: one question, asked once
  |
series   the rules: settlement_sources[] { name, url }
                    contract_url
                    contract_terms_url
```

[The Polymarket Gamma API](https://predictionmarkets.tools/tools/polymarket-gamma-api) is the other keyless one, and it puts the
rules on the market record itself — a block of prose sitting beside the condition id, the outcome
token ids and the dates. Everywhere else the answer is thinner than that, and knowing exactly how
thin is the point of the rest of this page.

Two things this is not. It is not how to pull outcomes after the fact, which is
[how to get resolved market history](https://predictionmarkets.tools/how-to/get-resolved-market-history). And it is not the
argument about who the resolver is and what they are bound by, which is
[who decides how a prediction market resolves](https://predictionmarkets.tools/guides/who-decides-the-outcome) — read that one
for the documents, this one for the endpoints.

## What the options are

**Kalshi, as fields.** Series, events and markets over REST, answering unauthenticated GETs, which
means the rules of a contract can be audited from a script by someone who has never opened an
account. Besides the settlement sources and the two contract links, a series record carries the
prohibitions on who may trade it — source-agency employees, holders of material non-public
information — which is a rule about you rather than about the outcome and appears nowhere else in
this category. One caveat carried over from the filed terms themselves: the links are provided for
convenience and are not the binding document. The PDF is.

**Polymarket, as prose.** Gamma is a catalogue: events with child markets, each market carrying its
slug, condition id, outcome token ids, start and end dates and the resolution rules text. That text
is where the source and the edge cases live, and it is also where the fallback lives, because the
mechanism behind it is not Polymarket's judgement. An outcome is proposed to the UMA optimistic
oracle against a bond, with a challenge window; an undisputed proposal settles as correct, a
disputed one goes to UMA's Data Verification Mechanism, where stakers commit votes over 24 hours
and reveal them over a further 24, and a dispute resolves on a minimum 65% majority of staked UMA
behind one outcome. Reading the rules tells you what should be decided. It does not tell you who
will be reading them when it is.

**Limitless, as a policy attached to the market type.** Markets are addressed by slug on
[the Limitless API](https://predictionmarkets.tools/tools/limitless-api), and the resolver is a property of what kind of market it
is rather than a document named per question: Pyth Network resolves the majority automatically at
the deadline, a Chainlink time-weighted average price handles short-cadence crypto up-or-down
markets so a single spike at the boundary does not decide them, and custom event markets are
reviewed by the Limitless team within 24 to 72 hours of the deadline depending on complexity and
data availability. The fallback is published as a policy rather than as a clause: where the
criteria cannot be applied, Limitless treats the market as misresolved and refunds the original
amount staked, not the dollar a winning share would have paid.

**Futuur, where the schema is the documentation.** There is no written guide behind
[the Futuur API](https://predictionmarkets.tools/tools/futuur-api) — the OpenAPI description served from the API host is the whole
of it, which makes it unusually easy to see what the venue does and does not model. An event
carries `status` (open, stopped, resolved, cancelled, paused, reversed), a nullable `resolution`
id, a `resolve_date`, a `bet_end_date`, a `resolution_mode` of exclusive or non-exclusive, a
`markets_correlation` of linked or independent, and a `cancellation_reason` of up to a thousand
characters. What it does not carry is a resolution-source field of any kind:

```python
# Futuur v2.0: what the event record answers about resolution, and what it does not.
for field in ("status", "resolution", "resolve_date", "bet_end_date",
              "resolution_mode", "markets_correlation", "cancellation_reason"):
    print(field, event.get(field))

# The public source the editorial team reads is not a field anywhere. It is a sentence in here:
print(event["description"])
```

Two of those values are worth pausing on. `reversed` says in one word that a settled outcome is not
always final. And `markets_correlation` decides whether the prices of an event's outcomes are
constrained to sum to one, which is a rule about the book rather than about the world and is just
as capable of losing you money.

**Predictefy, for the cross-venue version.** [Predictefy](https://predictionmarkets.tools/tools/predictefy) is the only product
here that treats rules equivalence as a computed quantity. Its arbitrage rows carry a `matchScore`,
a `matchBand` and a `matchDifferences` list produced by an automated judge reading the two venues'
published resolution rules, banded as verified equivalence at 100, minor differences from 85 to 99
and material differences from 60 to 84 — and the documentation states plainly that the score is not
a probability that the two markets settle identically. The cluster `similarity` beside it is raw
embedding similarity and is explicitly not called confidence. Resolution-equivalence gating applies
only at the arbitrage endpoint; the discrepancies endpoint deliberately does not apply it, so a
price gap listed there has not been checked against the rules at all. The cost of looking is that
nothing is readable without a key:

```bash
# Every Predictefy data route answers 401 without this. The health check is the only open one.
export PREDICTEFY_API_KEY="YOUR_API_KEY"
```

## Where this breaks

**The rules are not on the object you queried, and a market fetch alone will not carry them.**
This is the mistake that survives a code review, because the response looks complete: a title, a
close time, a price, a status. On Kalshi the binding terms hang off the series, two hops up. On
Polymarket the rules sit on the market but the event above it is what groups the questions a reader
thinks of as one thing. Any pipeline that stores markets and not their parents has thrown the rules
away before the first row lands, and the repair is a schema change rather than a second request.

**"Resolution source" is three different kinds of object wearing one column name.** A named
document with a publication time. A named agency, sometimes a ranked list of them where the second
decides if the first is silent. An oracle with a bond, a challenge window and a token-holder vote
behind it. These do not normalise: a column holding "Bureau of Labor Statistics", "the Limitless
team" and "UMA DVM" is a column you cannot sort, filter or reason about, and the cross-venue feeds
that publish one have flattened a difference to get it. Predictefy is the honest version — it
scores the gap and refuses to call the score a probability — and even that is a number about two
texts rather than about two outcomes.

**The rules text is prose, and no amount of parsing makes it structured.** The sentence that
decides a contested settlement is a clause in a paragraph: which print of a statistic counts,
whether a revision published next week moves anything, what happens if the source publishes late or
not at all. Regular expressions over it produce a field that is right until the week it matters.
The thing to automate is retrieval and diffing — store the text, hash it, alert when it changes —
and leave the reading to a person. [What a temperature market actually settles
on](https://predictionmarkets.tools/guides/what-a-temperature-market-settles-on) is one worked example of how much of the answer
is in a clause nobody extracted.

**Terms can be amended after a market is listed, and the amendment is published, not pushed.** US
exchanges reserve the power to designate a replacement source where the original becomes
unreliable or unavailable; Polymarket's international platform publishes a clarification on chain
for oracle voters to weigh, which cannot change the fundamental intent of the question but can
change which real-world result counts. Nothing in any of these APIs is a change feed for that. A
rules string cached the day a position was opened is not necessarily the string that settles it,
which makes "re-read the rules before close" a scheduled job rather than a habit.

**The title is not the rule, and the clause that decides you is usually not in it.** A question
reading "Will X happen by December 31" is a summary written to fit a card; the rule underneath it
names the publication, the timestamp, the rounding, the tie-break and what happens when the event
half-happens. Every venue here says some version of this about itself, and it is also why two
venues can list what looks like the same question at two different prices — which is
[why the same contract costs two prices](https://predictionmarkets.tools/guides/why-the-same-contract-costs-two-prices), and is
sometimes a real disagreement about probability and sometimes two different contracts.

## If you outgrow this

If the question is really "are these two markets the same market", that is a cross-venue problem
before it is a rules problem: [tools that cover more than one venue](https://predictionmarkets.tools/collections/cross-venue) is
the listing, and [Adjacent vs DepthFeed vs Predexon](https://predictionmarkets.tools/compare/cross-venue-prediction-market-data)
is the head to head. Read the match score as what it is — a judgement about two texts — and keep
the two rules strings beside it, because when a pair settles differently the difference will be in
the strings and not in the number.

And if none of this is yet obvious, the mechanism under all of it is on one page:
[what a prediction market actually is](https://predictionmarkets.tools/guides/what-a-prediction-market-is) explains why a contract
that pays a dollar on a condition needs a written condition at all, which is the thing that makes
the rules text the product rather than the packaging.

## FAQ

### Is the resolution source a field I can filter on?

On Kalshi, yes — the series record carries a settlement_sources array of names and URLs, so a script can group markets by who publishes the number. Nowhere else in this catalogue. Polymarket puts the source inside the rules prose, Futuur's schema has no such field at all, and Limitless attaches a resolver to the market type rather than naming a document per market.

### Can the rules change after I have taken a position?

Yes, and every venue reserves the power in writing. A US exchange can designate a replacement source where the original becomes unavailable, and Polymarket's international platform publishes clarifications on chain for oracle voters to weigh. The API consequence is that a rules string cached at listing is not the string that settles the market — re-read it before close.

### What happens when the rules cannot be applied to the real-world result?

It depends on the venue and it is rarely a dollar. Limitless treats an unapplicable rule as a misresolution and refunds the amount staked rather than the payout a winning share would have had. On Polymarket a token-holder vote can return Unknown, in which case both sides redeem at 50 cents. Futuur's schema carries a cancellation_reason and a reversed status.

### Do I need an account to read a market's rules?

Not on Kalshi, Polymarket or Limitless — their read endpoints answered unauthenticated requests when the cards were verified in September 2026, and Futuur's schema and reads are open too. Predictefy is the exception in this catalogue — every data route answers 401 without a key, so its cross-venue rules scoring cannot be inspected before signing up.

## Sources

1. [Market resolution](https://docs.limitless.exchange/user-guide/market-resolution) — Limitless Exchange, read 2026-09-21
2. [Cross-venue intelligence](https://docs.predictefy.com/guides/cross-venue/) — Predictefy, read 2026-09-21
3. [How does UMA's oracle work?](https://docs.uma.xyz/protocol-overview/how-does-umas-oracle-work) — UMA Protocol, read 2026-09-21
4. [Futuur API v2.0 OpenAPI schema](https://api.futuur.com/docs/schema/) — Futuur, read 2026-09-21
5. [Industry Filings](https://www.cftc.gov/IndustryOversight/IndustryFilings/index.htm) — U.S. Commodity Futures Trading Commission, read 2026-09-21

*Last updated 2026-09-21. A reference page, corrected in place — not a dated post.*