# Futuur API

One question, two order books — play money and real money, selected per request.

*https://predictionmarkets.tools/tools/futuur-api · Prediction Market Data APIs*

## Facts

### At a glance

| Field | Value |
| --- | --- |
| Vendor | Futuur |
| Category | Prediction Market Data APIs |
| Job | realtime |
| Website | https://api.futuur.com/docs/ |
| Pricing model | commission |
| Free tier | true |
| Open source | false |
| Licence | none |
| Self-hosted | false |
| Tested hands-on | false |
| Last updated | 2026-09-19 |

### Availability

| Field | Value |
| --- | --- |
| Jurisdictions | global |
| Open to US persons | false |
| KYC required | false |

### Markets

| Field | Value |
| --- | --- |
| Subjects | politics, sports, macro, crypto, science, culture, business |
| Settlement | crypto |
| Resolved by | Futuur's editorial team resolves each event against the public source named in its rules and voids anything it cannot resolve fairly; the API reports the outcome on the event record rather than through a separate feed. |

### Economics

| Field | Value |
| --- | --- |
| Taker fee | 1.25 |
| Maker fee | 0 |
| Liquidity model | amm |
| Platforms | library |
| AI features | none |

### Interfaces

| Field | Value |
| --- | --- |
| API | true |
| WebSocket | false |
| Scripting | none |
| Python | false |
| MCP server | false |
| Export | json |

### Capabilities

Yes: order_book, automation, live_trading, paper_trading, portfolio_tracking

No: charting, screening, backtesting, calibration_scoring, cross_venue, alerts, news, tax_reporting

*Verified: pricing 2026-09-19; availability 2026-09-19.*

## What it is

A small, conventional REST API over a venue with one unconventional property: Futuur lists the
same question twice, in play-money Ooms and in real money, with separate books and separate
prices. That single fact runs through the whole interface. `currency_mode` is a parameter on
almost everything, and on the order book and the price history it is **required** — a call without
it answers HTTP 400 with a validation error rather than picking a default.

The v2.0 surface is 21 documented paths. Reads: the events list, event detail, related events,
price history, a tax estimate per event, a per-outcome order book, and a public trade record.
Writes: limit and market orders, single and in batches, cancel by id, batch cancel and cancel all,
plus account balances and ranking. There is an OpenAPI 3.0.3 description served straight from the
API host, which is the document to generate a client from.

Vocabulary changed between versions and the old words are still in circulation. An **event** is
what v1 called a question; a **market** is what v1 called an outcome. Each event holds several
markets, related by a `markets_correlation` field that is either `linked_prices` — prices sum to
one, and trading one moves the others, which is the default — or `independent`.

## Availability

The API host has no geographic gate and answered this machine without credentials on 19 September
2026. The account behind a key does have one: Futuur's real-money side is barred to residents of
the United States, the United Kingdom, Canada and much of the EU, while play money is open
everywhere. An account is an email address rather than a verified identity, so there is no KYC
step in the way of a key.

That split is the thing to design around, not around the host. A reader in a restricted country
can read every real-money price this API publishes and cannot take a position at any of them.

## Pricing

Nothing is charged for API access. The venue's fee is taken out of the fill, and this card records
it in the catalogue's common measure — the effective taker charge at a price of 50 cents, 1.25% of
the dollar of payout, with nothing taken from the resting side. See the
[Futuur](https://predictionmarkets.tools/tools/futuur) card for the schedule behind that number.

The fee is not something you have to model separately when reading the book: each ladder level
comes back carrying `total_fees` and `cumulative_fees` beside its shares and amount, so the cost
of sweeping to a given price is in the response.

The rate limit is generous and clearly documented — 2,000 requests a minute and 1,000,000 a day
per user, shared across all endpoints and querystrings, with 429 and a `Retry-After` when
exceeded. The vendor adds two pieces of guidance that are worth following: order-book and event
reads are served from a cache that is a few seconds old, so polling faster than once a second per
resource returns the same bytes and spends quota, and `include_mine=1` should be passed only on
the calls that actually need your own orders embedded, because it takes the request off the fast
path.

## Markets & resolution

Broad and long-tailed — politics, sports, macro, crypto prices, entertainment, science — with a
tag tree deep enough that the categories endpoint returned 194 entries. Volume is thin next to the
large venues: on 19 September 2026 the events list returned **747 open events in play money and
608 in real money**, so most questions run in both modes and roughly one in five is Ooms-only.

Resolution is editorial. Futuur's team settles each event against the public source named in that
event's own rules and voids anything it cannot settle fairly. There is no oracle, no bond and no
dispute window, so nothing in the API resembles a proposal or challenge feed — the outcome simply
appears on the event record. Anyone writing settlement logic reads `status` and `resolution`, and
has to accept that the adjudicator is the venue.

Price history comes back as a chart series per outcome — a list of named series of `x` timestamps
and `y` values in percent — rather than as OHLC candles. There is no bucket width to choose and no
interval parameter: you get the points the venue recorded, which for a young market is a couple of
days of dense ticks.

## Integrations

REST and nothing else. **There is no WebSocket**, no streaming endpoint and no push channel
anywhere in the schema, so live means polling inside the published limits. There is also no
first-party SDK in any language, no MCP server, and no client library named in the documentation.

Authentication is HMAC rather than a bearer token, which is the part that costs an afternoon. Three
headers go on every authenticated request: `Key` with the public key, `Timestamp` in Unix form, and
`HMAC` with a SHA-512 hexdigest computed over the request's headers plus its GET and POST data,
ordered alphabetically by key, signed with the private key. Get the ordering wrong and the request
is rejected and counted against a per-IP failure limit rather than your account's.

One write-side rule that will surprise a retrying client: submitting the same POST twice inside one
second returns a duplicate-action error rather than a second order.

## Limitations

- **An unauthenticated call to the orders endpoint returns 200 and an empty page**, not 401. On
  19 September 2026 `/v2.0/orders/` answered a request with no credentials with a normal paginated
  envelope and zero results. A client whose signing has silently broken sees no open orders rather
  than an error, which is the worst possible failure mode on a trading path.
- **No streaming.** Polling is the only live option, against a cache that is a few seconds stale by
  the vendor's own description.
- **No SDK and no MCP server.** The OpenAPI description is the compensation; generate rather than
  hand-write.
- **Two prices per question, and the API will not choose for you.** Any code that omits
  `currency_mode` either 400s or, on endpoints where it is optional, silently answers about the
  wrong book.
- **Real money is closed to a long list of countries**, including the US, UK, Canada and much of
  the EU, however open the data is.
- **Documentation lives in the schema.** There is no written guide beyond the Redoc page and the
  introduction embedded in the specification, so behaviour such as the empty-orders response is
  found by calling rather than by reading.

## Alternatives

For a venue API of the same shape with far more volume behind it, the
[Polymarket Gamma API](https://predictionmarkets.tools/tools/polymarket-gamma-api) and
[Polymarket CLOB API](https://predictionmarkets.tools/tools/polymarket-clob-api) are keyless to read and streaming, and the
[Kalshi API](https://predictionmarkets.tools/tools/kalshi-api) is the regulated US equivalent. For the same play-money idea with
an open-source server behind it, the [Manifold API](https://predictionmarkets.tools/tools/manifold-api). If Futuur is wanted
alongside other venues in one schema, no aggregator in this catalogue currently covers it — check
the venue list on [FinFeedAPI](https://predictionmarkets.tools/tools/finfeedapi) or [Predictefy](https://predictionmarkets.tools/tools/predictefy) before
assuming otherwise.

## FAQ

### Can I read Futuur market data without an API key?

Yes. On 19 September 2026 the events list, the event detail, the price history and the order book all answered unauthenticated requests. Only the account endpoints refused, and one of them did not — see the card for the empty-list trap on the orders endpoint.

### Which API version should I use?

v2.0, addressed as /v2.0/ on api.futuur.com. The vendor's own schema marks it as the latest and points at a separate, deprecated v1.0 documentation site. Some older integrations still call /api/v1/, which still answers.

### What is currency_mode and why did my request fail without it?

Futuur runs each question twice — once in play-money Ooms and once in real money — with separate books and separate prices. The order book and price-history endpoints treat currency_mode as required and return HTTP 400 with a validation error when it is missing, because there is no default answer to give.

### What are the rate limits?

2,000 requests a minute and 1,000,000 a day per user, shared across every endpoint and path. Exceeding them returns 429 with a Retry-After header. Requests that carry HMAC headers and fail authentication are limited per IP instead.

### How does authentication work?

HMAC, not a bearer token. Three headers — Key with your public key, Timestamp in Unix format, and HMAC carrying a SHA-512 hexdigest built from the request's headers and its GET and POST data sorted alphabetically by key, signed with your private key.

## Also from Futuur

- [Futuur](https://predictionmarkets.tools/tools/futuur.md)

## Background

- [Where weather data comes from and what you may do with it](https://predictionmarkets.tools/guides/where-weather-data-comes-from.md) — Observations, model output and archives are three products with three licences. The forecast is the cheap half; a clean observation history is not.

- [Why the same contract costs two different prices on two venues](https://predictionmarkets.tools/guides/why-the-same-contract-costs-two-prices.md) — Two venues quoting one outcome are quoting two contracts. What the gap between the prices is made of - rules, fallbacks, fees, collateral, exits, eligibility.
- [What a trade actually costs on a prediction market](https://predictionmarkets.tools/guides/what-a-trade-actually-costs.md) — Venues publish trading fees in four incompatible units, so 3.00% on one can be cheaper than 1.75% on another. How to convert them, and what else takes a cut.

## Also worth comparing

- [Limitless API](https://predictionmarkets.tools/tools/limitless-api.md) — REST and WebSocket for markets, books, candles and trading on Base.
- [Polymarket CLOB API](https://predictionmarkets.tools/tools/polymarket-clob-api.md) — Order books, prices and order placement on Polymarket's matching engine.
- [Polymarket Gamma API](https://predictionmarkets.tools/tools/polymarket-gamma-api.md) — Polymarket's read-only catalogue of events, markets, series and tags.
- [Kalshi API](https://predictionmarkets.tools/tools/kalshi-api.md) — REST, WebSocket and FIX access to a CFTC-regulated event exchange.
- [Manifold API](https://predictionmarkets.tools/tools/manifold-api.md) — Every read is keyless, the server is MIT-licensed, and the currency is play money.
- [Polymarket US API](https://predictionmarkets.tools/tools/polymarket-us-api.md) — A keyless public gateway for reading, and a signed key behind KYC for trading.