​
Event type filters. GET /events accepts a type parameter with the values standard, leaderboard, and short_market. The old isLeaderboard=true parameter remains as a deprecated alias for type=leaderboard.
​
GET /events now includes halted markets for Sports events, and GET /events/details returns halted markets for every event. A sports fixture whose Moneyline is halted therefore stays in the listing instead of disappearing. Check status per market: only open markets accept orders.
​
One listing for every status. GET /events now accepts a comma-separated status (e.g. status=open,pending,live,halted) and isFuture=all (also isFutureTradable=all), so a single paginated request returns regular and future events across every listed status. Existing single-value calls behave exactly as before. See the Events guide.
​
Webhook replay. POST /partner/webhook-events/replay lets you request redelivery of a time range or specific event ids — including events already dropped after exhausting all 8 delivery attempts. See the Partner webhooks guide.
​
Secret rotation overlap window. Rotating your partner API secret, webhook endpoint secret, or brand API key/secret pair no longer invalidates the old credential immediately — it keeps verifying for a short overlap window so you have time to switch over.
​
  • Wallet instructions lookup, order lookup by clientOrderId, and additional limit fields on event/market responses — new partner-facing fields and endpoints added in response to partner integration feedback.
  • Error catalog cleanup. Several error codes and names that collided with other, unrelated errors were fixed (see the error catalog, which is generated directly from the error definitions and is the authoritative source — other reference pages are maintained separately and can lag behind it).
  • pending clarified as an acknowledgement value from POST /orders, not a stored order status — it is never persisted on an order row.
​
A pass through partner-reported documentation gaps, fixed in place rather than listed separately here — reservation-check timeout/retry semantics, the IOC/FOK partial-fill release signal, webhook/reservation-check authentication (HMAC, not bearer/API-key), the order-status enum (seven stored statuses, pending is not one of them), and rate-limit behavior on the order APIs (admin-configurable, disabled by default).