> ## Documentation Index > Fetch the complete documentation index at: https://docs.parlayx.com/llms.txt > Use this file to discover all available pages before exploring further. # Limitless > Discovery, sizing, order controls and position semantics for Limitless. 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](/api-reference/limitless/list-markets) in the API reference. `@parlayx/sdk` and Python `parlayx` reach all of them through `client.limitless`. ## Addressing a market Start with [List Markets](/api-reference/limitless/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: | Order | `amount` is in | | - | - | | Immediate BUY (FAK, FOK) | USDC | | SELL | Outcome shares | | GTC limit | Outcome shares | 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`. > [!WARNING] > > 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. > [!WARNING] > > 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: | Value | Meaning | | - | - | | `ACCEPTED` | The replacement was accepted. Read its status and the order's fills for execution. | | `REJECTED` | The replacement was refused. `replacementError` carries the reason. | | `SKIPPED` | Cancellation did not confirm, so no replacement was submitted. | | `CONFLICT` | A successor already exists for this order. See below. | | `UNKNOWN` | The outcome is undetermined. Retry the same terms. | `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. > [!NOTE] > > 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](/api-reference/limitless/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](/api-reference/limitless/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. > [!WARNING] > > 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](/api-reference/limitless/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. > [!WARNING] > > 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. > [!NOTE] > > 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](/api-reference/limitless/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. > [!WARNING] > > 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](/api-reference/limitless/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. > [!WARNING] > > A failed balance read returns 503. Do not treat that response as zero. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.