Changelog

Every change to the operator contract is listed here, newest first, with its date.

Additive changes (a new endpoint, a new optional field, a new response field, a new event type, a new error code) arrive under /v1 without notice and are listed here. A breaking change is never published under /v1. It opens beside it as /v2.

The entry for each deprecated item names the item, its replacement and the Sunset date when one is set. The responses of a deprecated endpoint carry the Deprecation, Sunset and Link headers, and Link points to this page. We announce an item at least 90 days before the release that removes it. /v1 stays available for at least 12 months after /v2 is generally available, and we announce the Sunset date at least 180 days in advance.

2026-10-07

A new error code for POST /v1/positions. It is additive and arrives under /v1. Nothing is deprecated.

idempotency_key_in_progress (HTTP 409) means that an earlier request with the same Idempotency-Key is still being processed, for example when your client timed out and sent the retry while the first attempt was still running. Nothing is applied by the request that gets it, and its price is not checked. The response carries a Retry-After header, which is 1 second today. When the earlier request timed out or its connection dropped, the code can last for up to 30 seconds, until we know that request is over.

Wait for the Retry-After period and send the request again with the same Idempotency-Key and the same body. Once the first request has finished, the retry returns the position it opened, or is evaluated as a new request if it opened none. Do not send the retry with a new key: a new key is a second request, and it can open a second position next to the first one. The embeddable widget already retries this way.

2026-10-06

Two new webhook events tell you when a widget session opens or closes a position. Both are additive and arrive under /v1. Nothing is deprecated.

position.opened arrives when a user opens a position in the widget, and position.closed arrives when a user closes one. You did not send those requests, so until now you could only learn of the debit or the credit by reading the position again. Each event arrives once per position. A repeated close sends nothing more.

You get no event for a request that you send yourself. A position that you open or close with your tenant API key sends neither event, because you already hold the response. A limit order that fills still sends order.filled, and it does not send position.opened.

position.opened carries the position id, external_user_id, market_slug, outcome_id, the stake, the price at open and open_transaction_id. position.closed carries the same identifiers, the payout that the user received, the close_price and the settlement_transaction_id of the closing transaction. occurred_at is the time of the open or the close. The Webhook guide has the full event bodies. As for any new event type, answer an event that your receiver does not know with 2xx and ignore the body.

2026-10-05

Void corrections. We can now correct a market that we voided by mistake, and a market that we resolved when it should have been voided. This entry was published as notice ahead of the release, and that release has shipped: we send the events below from today. Both changes are additive and arrive under /v1. Nothing is deprecated.

Two new events. position.void_corrected arrives for each position that a void correction moves from voided to settled_win or settled_loss, or from settled_win or settled_loss to voided. A position that the correction leaves in its state sends nothing. market.void_corrected arrives once for each market that moved between voided and resolved, with the previous and the new status and outcome.

The set of position states still does not change, but voided is no longer final for a position that a market void refunded. A moved position never receives a second position.settled or position.voided, and a moved market never receives a second market.resolved or market.voided. When a correction takes back a refund or a payout that the user has already spent, we post correction_shortfall_credit first, as for a settlement correction. The same rules as above apply: events have no order, so read the position again with GET /v1/positions/{id} when one arrives. The Webhook guide already shows the two event bodies.

2026-10-04

Settlement corrections. We can now correct a market that we resolved to the wrong outcome. This entry is notice ahead of the release that posts the new ledger value below. All three changes are additive and arrive under /v1. Nothing is deprecated.

The entry_type set of GET /v1/transactions is open. The set can gain values without a new API version, and we list each new value on this page on the day it ships, with no notice period. If a transaction has an entry_type that you do not know, keep it. Read its signed amount and store or show the raw entry_type text. Do not fail, drop or retry the row. The sign rule of amount holds for every value, so the sum of your amount values still matches the balance of the user. An integration that fails on an unknown value is out of contract. Every other enum in the API stays closed.

New value correction_shortfall_credit. A correction can take a payout back from a user who has already spent it. When the balance of the user is below that payout, we first post a correction_shortfall_credit for the difference, and then the reversal. The amount of the new transaction is always positive. It lifts the balance to exactly the payout that the reversal takes back, so the balance never goes below zero. The reversal keeps the type settlement_credit, carries a negative amount, and its reverses_transaction_id points at the original. GET /v1/transactions returns the new value as a transaction of its own, and you can filter on it with ?entry_type=correction_shortfall_credit.

Two new events. position.settlement_corrected arrives for each position that a correction moves between settled_win and settled_loss. A position that the correction leaves in its state sends nothing. market.resolution_corrected arrives once for each market whose resolved outcome we replaced.

The set of position states does not change, but settled_win and settled_loss are no longer final. A correction can move a position from one to the other, and position.settled is never sent twice for one position. The new event is how you learn of the move. A moved position keeps its first settled_at. Events have no order, so market.resolution_corrected can arrive before the position.settlement_corrected events that it announces. When one of these events arrives, read the position again with GET /v1/positions/{id} and store the state and payout from that response, so that a late event never replaces a newer state. The Webhook guide has the full event bodies.

2026-09-26

The developer portal is live. The /v1 contract is as this portal describes it. No item is deprecated.