Skip to main content
POST
Place orders
Submit one or more orders. The endpoint accepts a batch — per-order results come back in data.createdSessions, positionally with your input orders array. Each entry is either a successful { matched, unmatched } result or an { error, errorType } failure.

Request

POST /session/v3/place

Order fields

Order types

limit

The default order type. Executes against any matching liquidity at your price or better as a taker (with taker commission), and rests any remainder on the book as a maker. A limit order can finish fully matched, fully resting, or partially matched with the remainder resting.

post

Create a resting offer. If the order would match existing liquidity when placed, the server rejects it (rejected_order_type_rules, e.g. "post order cannot have matches").

postArb

Behaves like post, but you may post even when the order would match, only if your American odds are within 1% of the odds on the resting order you would match. If the price difference is more than 1%, the place is rejected. Examples:
  • Best offer +100 and you post +100 — post is rejected (it would match); postArb is allowed.
  • Best offer +200 — postArb at +190 is rejected (too far from +200). About +198 is at the edge of the 1% band vs +200.
  • Best order −200 — the band extends to about −202 on the negative side (same 1% rule).
  • With +100 on the book, −101 is the reference limit on the other side for the 1% tolerance.
postArb avoids taker fees across a normal trade — you are not charged taker fees on this flow the way you would be if you lifted resting liquidity as a taker. Orders placed as postArb are flagged with isPostArb: true on their user feed and price feed updates; the field is omitted for other order types. The place response itself does not include the flag.

fillAndKill

Execute immediately as a taker against whatever size is available at your price or better, and cancel any remainder. A fillAndKill never rests on the book. A partial fill is a successful outcome: if you send bet: 1000 and only 400ofmatchableliquidityexists,youarefilledfor400 of matchable liquidity exists, you are filled for 400 and the remaining $600 is cancelled — the response is a success, not an error. The order is rejected (rejected_order_type_rules, "fill and kill has no matches") only when there is no matchable liquidity at all. See the Fill And Kill scenarios in the examples below.

fillOrKill

All-or-nothing. Your entire bet must match immediately at your price or better, otherwise the whole order is rejected — including any fills it made along the way, which are rolled back. A fillOrKill never rests on the book, and you are never left partially filled. Use it when a partial position is worse than no position, for example when the order is one leg of a hedge you can only execute in full. Rejections carry errorType: rejected_order_type_rules with one of two messages, which distinguish “nothing was there” from “not enough was there”:
  • "fill or kill has no matches" — no matchable liquidity at your price.
  • "fill or kill matched but not fully" — some liquidity matched, but not your full size. Those fills were rolled back.
A residual of **10orless∗∗countsascomplete:a‘fillOrKill‘for10 or less** counts as complete: a `fillOrKill` for 1,000 that matches 992succeeds,becausethe992 succeeds, because the 8 that could not be filled is below the minimum size that could ever rest on the book. A residual larger than $10 rejects the order.

Response

array
Per-order results, positional with the input orders array. Each entry is either a successful place or an error.

Examples

Scenario 1 — Match orders with no leftover liquidity

Three orders that all match instantly with available liquidity.

Scenario 2 — Limit order with leftover liquidity

A limit order for 300 that partially matches and leaves the remainder resting.

Scenario 3 — Fill and Kill, full match

Scenario 4 — Fill and Kill, no match

A fillAndKill with no match returns a per-order error.

Scenario 5 — Fill or Kill, not enough liquidity

fillOrKill is the all-or-nothing counterpart to fillAndKill. Where a fillAndKill for 1,000against1,000 against 400 of liquidity fills 400andcancelstherest,a‘fillOrKill‘rejectsthewholeorderandrollsbackthat400 and cancels the rest, a `fillOrKill` rejects the whole order and rolls back that 400 — you are never left partially filled.
With no matchable liquidity at all, the same order is rejected with "fill or kill has no matches" instead.

Scenario 6 — postArb vs post when the book would match

post rejects an order that would match resting liquidity (for example, best offer +100 and you try to post +100). postArb allows that situation when your odds are within 1% of the order you would match — so the same +100 post can succeed as postArb, and you avoid the taker fees you’d pay across a normal trade. If your price is too far from the resting quote (e.g. best offer +200 but you send +190), postArb is rejected.

Scenario 7 — moneyline1x2 (soccer three-way)

moneyline1x2 is the soccer three-way market — home / away / draw — placed as a yes/no bet on the outcome named by market. Below, yes on the draw at +250.
To bet that the home team does not win, send side: "no" and set market to the home participant’s id.

Live delay

Orders placed on a game marked as live follow these rules:
  1. If the order does not match any existing liquidity, it is placed immediately.
  2. If the order does match existing liquidity, it incurs a delay before execution.
  3. Different leagues have different live delay periods:
    • NFL, UFCMMA, NCAAF — 3 seconds.
    • NCAAB, NBA — 5 seconds.
    • ATP, WTA — 8 seconds.
    • Default — 10 seconds.
  4. After the delay, the order attempts to execute:
    • If the odds improve, it matches instantly.
    • If the odds decrease, it does not match.

Per-order errors

Example with multiple places, some erroring:

Authorizations

Authorization
string
header
required

Pass your auth token in the Authorization header. The Bearer prefix is optional; the server also accepts a signed auth cookie or a token field in the request body.

Body

application/json
orders
object[]
required

Response

Per-order results (positional with input).

data
object