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

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 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:

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 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. 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 — 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, 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 — 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:

# 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 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:

# 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 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, 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 is the listing, and Adjacent vs DepthFeed vs Predexon 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 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.