trade capability.
Every endpoint is listed under Limitless
in the API reference. @parlayx/sdk and Python parlayx reach all of them
through client.limitless.
Addressing a market
Start with List Markets. Each tradable CLOB market supplies amarketSlug and, under outcomes, each outcome’s
tokenId. Submit the market’s marketSlug and the chosen outcome’s tokenId.
Grouped markets appear as individual child markets.
Follow nextPageToken until it is null. Pages are point-in-time reads, not
slices of one snapshot, so a market can be missed or seen twice across a walk.
Deduplicate by marketSlug.
Sizing and pricing
Units depend on the side and the policy:
A FAK BUY can be sized in shares instead. Set
timeInForce.amountUnit to
"shares" and supply timeInForce.maxFillPrice; amount then means gross
shares requested. The quantity must land exactly on the market’s share tick or
the order is rejected before signing. A better execution price reduces the
dollars spent, it does not increase the signed share count, and fees can reduce
the net shares received. The readback reports the requested quantity in size
with amount null. amountUnit is accepted only on a FAK BUY; omitting it, or
sending "usd", keeps dollar sizing.
Market-specific price ticks, share ticks and minimum resting sizes are all
enforced before placement.
Bounding the fill price
A FAK SELL can settimeInForce.minFillPrice as a per-share floor, and a FAK BUY
can set timeInForce.maxFillPrice as a per-share ceiling.
A SELL floor rounds up to the market’s price tick before signing and a BUY
ceiling rounds down, so the bound is never loosened. Both stay within 0.001 to
0.999. A bound that cannot be represented conservatively is rejected.
Execution policy
FAK fills the available liquidity and cancels the remainder. FOK fills entirely or cancels. A GTC limit order usestype: "LIMIT", a price between 0.001 and
0.999, and timeInForce: { "type": "GTC" }; it rests until it fills or is
cancelled.
Markets with a taker delay acknowledge FAK, FOK and crossing GTC orders before
matching begins. Those orders stay open with no reported fills while execution is
pending, so poll the order and its fills for the outcome.
Self-trade prevention
A GTC order acceptsCANCEL_MAKER, CANCEL_TAKER or CANCEL_BOTH, defaulting
to CANCEL_MAKER. A rejection at placement reports a cancelled order with
LIMITLESS_STP_TAKER_REJECTED.
Submitting
Retry an unresolved submission with the sameIdempotency-Key and the same body.
A different key creates a different order.
A 201 means the order was accepted, not that the venue holds it. The status it
returns is the order’s recorded state when the response was produced, so read the
order back to learn whether it rested or filled. A retry under the same idempotency
key returns the order it already created, carrying whatever state that order has
now. Read its fills for execution.
Changing an order
Replacement cancels the original and submits its successor once cancellation is confirmed. It does not use the venue’s native cancel-replace route.replacementOutcome reports what happened to the submission:
cancelError and replacementError carry a safe code and never a raw upstream
message. Validation, authentication, insufficient balance and disabled-venue
errors return REJECTED; transport, protocol and unclassified failures stay
UNKNOWN. Retry the same terms after an unknown outcome.
Recovering from CONFLICT
Each original order and trader has one successor identity, so retrying the same original ID and replacement body after an unknown outcome is safe. A different body after an accepted replacement returnsCONFLICT rather than placing a
second successor. To requote an accepted order, replace the successor’s ID.
Corrected terms advance past a successor only when that successor is definitively
rejected with zero filled shares. A fill total that is unknown never permits the
advance. One request follows at most three identities in the chain.
Concurrent corrections compete for the same successor identity, so only one of
them can create the order. When a conflict remains, the response returns the
last order ID it reached. Read that order to see where the chain stands before
following up.
Cancelling
Cancel Order returns the order’s actual state. An order that has already reached a terminal state returns that state rather than erroring, so inspect it. Cancel All Orders narrows withorderId, repeated 1 through 5 times, or with marketSlug. The two cannot be
combined. Each result names the order ID and one of CANCELLED, COMPLETED,
NOT_FOUND or UNKNOWN. Another trader’s ID returns NOT_FOUND, and UNKNOWN
is not proof the order is still live.
A sweep, filtered or not, processes up to 5 active orders per page. Follow
nextPageToken with the same filter until it is absent. The cursor keeps the
first page’s creation-time cutoff, so orders created later are excluded, and
continuing the cursor does not retry unresolved IDs. Retry those explicitly.
Reading orders and fills
Order IDs are issued by ParlayX, not by the venue. Orders are scoped to your trader and listed newest first, and another trader’s order is not visible to your key. Filter bytokenId or status, and follow nextPageToken for more pages.
A resting order’s summary can report null filled quantity, average price and
fees while fills already exist. Null means unknown, not zero. Read
Get Order Fills for progress;
terminal summaries are populated after reconciliation.
Positions and balance
Positions are derived from recorded fills and bounded by the pod’s on-chain balance for the token, sosize can read lower than that balance but never
higher. The bound is pod-wide, so where several keys trade the same token a sell
sized from size can still ask for more than that key alone can deliver. Filter
by tokenId to select one outcome.
redeemable has three states: true means resolved and redeemable, false means
known unresolved, and null means the classification is unavailable. mark,
valueUsd and unrealizedPnlUsd are populated only when redeemable is false
and a usable price exists. Render null as unknown, never as zero.
The venue’s minimum sell size is 0.0001 shares. A holding below that cannot be
sold and exits only by redemption once the market resolves. Resolved positions
are redeemed asynchronously, and a successful redemption releases collateral back
into the pod’s USDC balance.
On Get Balance, available and total
are USD amounts backed by native USDC on Base. available is the signing
address’s balance and does not subtract resting-order commitments, so several
resting orders can overcommit it. total covers every address the pod has held
and excludes the value of outcome shares.