Skip to main content
Limitless trades through the pod’s wallet using native USDC on Base. Reads and writes both use signed API authentication; submitting, cancelling or replacing an order needs a key with the 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 a marketSlug 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 set timeInForce.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 uses type: "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 accepts CANCEL_MAKER, CANCEL_TAKER or CANCEL_BOTH, defaulting to CANCEL_MAKER. A rejection at placement reports a cancelled order with LIMITLESS_STP_TAKER_REJECTED.
Self-trade prevention is wallet-scoped at the venue, so it can cancel another trader’s resting order in the same pod. Trader-scoped cancellation does not change that. CANCEL_TAKER preserves the resting maker order; CANCEL_MAKER and CANCEL_BOTH can remove it. Read each affected order for its reconciled status.

Submitting

Retry an unresolved submission with the same Idempotency-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.
Replacement is not atomic. A failed or unknown cancellation skips the submission, and a confirmed cancellation is still reported if the submission then fails. HTTP 200 carries per-step results, not a claim that every step succeeded.
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 returns CONFLICT 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.
Batch Replace Orders takes up to 2 distinct original IDs. The entries run concurrently with independent results, so one entry succeeding says nothing about the other.

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.
HTTP 409 means the cancellation is unresolved, which includes an order still being submitted without a confirmed venue ID. It is proof of neither refusal nor success. Read the order, then retry cancellation with the same order ID. Do not submit a replacement until cancellation is confirmed.
Cancel All Orders narrows with orderId, 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.
With neither filter the request cancels every active order this trader holds across every market. Send a filter unless a full sweep is what you want.
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 by tokenId 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.
Reconciliation is asynchronous, so a newly executed fill can appear later. An empty fills list is not proof that nothing filled: an order can reach a terminal state, rejected included, while the shares it bought are held on chain.

Positions and balance

Positions are derived from recorded fills and bounded by the pod’s on-chain balance for the token, so size 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.
A position is listed only while that on-chain balance can be read. While the read is unavailable the position is omitted rather than reported at its fills-ledger total, which can exceed the shares actually held. Treat a position that disappears from this view as unknown, not as closed, and confirm a close through the order that made it.
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.
A failed balance read returns 503. Do not treat that response as zero.