Futuur API

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 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 and Polymarket CLOB API are keyless to read and streaming, and the Kalshi API is the regulated US equivalent. For the same play-money idea with an open-source server behind it, the 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 or Predictefy before assuming otherwise.