Polymarket Order Types (2026): GTC, GTD, FOK and FAK Explained

What order types does Polymarket support?

Polymarket's documentation is blunt: "All orders on Polymarket are limit orders." A market order is a limit order priced to execute against the best resting orders, so the four types form two pairs. GTC and GTD decide how long an unfilled limit order stays open, and FOK and FAK decide what happens when an immediate order cannot fill completely. Post-only is a flag on a GTC or GTD order, not a fifth type.

How do limit and market orders behave on Polymarket?

A limit order names a price. If it crosses the spread, a buy at or above the lowest ask or a sell at or below the highest bid, it matches at once, and price improvement goes to the taker: a buy at $0.55 that meets a resting sell at $0.52 pays $0.52. Whatever does not fill stays open as GTC or GTD.

A market order takes its price from the current book and never rests, because "any amount that cannot fill is canceled." In the SDK, a market BUY takes amount in dollars and a SELL takes shares. maxPrice caps what a buy pays, minPrice floors what a sell accepts, and maxSpend sets an estimated all-in spend target that includes fees, which are otherwise charged on top.

How does a GTD order's expiration work?

expiration is a Unix timestamp in seconds. GTC orders send "0", and so do FOK and FAK orders, because neither rests. A GTD order carries the time it should end, under two rules from Polymarket's docs:

• It expires early. GTD orders "expire one minute before their stated expiration as a security threshold." For an effective lifetime of N seconds, set expiration to now plus 60 plus N.
• It needs a minimum runway. The expiration must be at least 3 minutes in the future, which makes the shortest effective lifetime about two minutes.

The SDK enforces the second rule before it signs anything, with the error "Expiration must be at least 3 minutes in the future." Over the raw API, the CLOB rejects orders that expire too soon, and its invalid expiration error covers timestamps that are in the past or invalid. This places a 30-minute post-only GTD bid with @polymarket/client 0.12.0, the latest release on 3 October 2026:

import { createSecureClient, OrderResponseErrorCode, OrderSide } from '@polymarket/client';
import { privateKey } from '@polymarket/client/viem';

const client = await createSecureClient({
  signer: privateKey(process.env.POLYMARKET_PRIVATE_KEY as `0x${string}`),
});

const market = await client.fetchMarket({ slug: 'your-market-slug' });
const assetId = market.outcomes.yes.tokenId!;

// Effective lifetime of 30 minutes, plus the 60-second security threshold
const expiration = Math.floor(Date.now() / 1000) + 60 + 30 * 60;

const response = await client.placeLimitOrder({
  assetId,
  side: OrderSide.BUY,
  price: '0.52',
  size: '10',
  expiration,
  postOnly: true,
});

if (response.ok) {
  console.log(response.orderId, response.status);
} else if (response.code === OrderResponseErrorCode.POST_ONLY_WOULD_CROSS) {
  console.log('This price would take liquidity, so quote further from the ask.');
} else {
  console.error(response.code, response.message);
}

When should you use FOK or FAK?

Use FAK when a partial fill is acceptable, and FOK when the order only makes sense at full size, such as one leg of a two-sided trade. FAK still needs at least one match. If nothing on the book meets your price limit, the CLOB rejects it with "no orders found to match with FAK order." FOK rejects the whole order with "order couldn't be fully filled" when depth runs out.

One SDK detail catches people. placeMarketOrder() defaults to FAK, but estimateMarketPrice() models FOK unless told otherwise, and an FOK estimate throws when the book is too thin for the full amount. Pass the same orderType to both:

import { createSecureClient, OrderSide, OrderType } from '@polymarket/client';
import { privateKey } from '@polymarket/client/viem';

const client = await createSecureClient({
  signer: privateKey(process.env.POLYMARKET_PRIVATE_KEY as `0x${string}`),
});
const assetId = 'YOUR_TOKEN_ID';

const maxPrice = await client.estimateMarketPrice({
  assetId,
  side: OrderSide.BUY,
  amount: '25',
  orderType: OrderType.FOK,
});

const response = await client.placeMarketOrder({
  assetId,
  side: OrderSide.BUY,
  amount: '25',
  maxPrice,
  orderType: OrderType.FOK,
});

console.log(response.ok ? response.status : `${response.code}: ${response.message}`);

Does Polymarket support post-only orders?

Yes. Polymarket added post-only orders in January 2026. Set postOnly: true on a GTC or GTD order, and it either rests on the book as a maker order or is rejected with "invalid post-only order: order crosses book." The API schema says post-only is "only supported for GTC and GTD orders," and the SDK throws before it submits a post-only FOK or FAK order.

Post-only also matters during maintenance. While the matching engine restarts, order requests return HTTP 425, and for two minutes after it returns, only cancels and post-only orders are accepted. Any other new order gets HTTP 503 with "code": "post_only_mode" and a retry delay in retry_after_seconds and the Retry-After header.

How do you set the order type in the CLOB API?

Over raw HTTP, an order is a signed EIP-712 struct inside a JSON body sent to POST https://clob.polymarket.com/order with the five L2 headers. The time in force is not part of the signature: orderType and postOnly are top-level fields, and expiration travels in the order object but sits outside the signed CLOB V2 struct.

A post-only GTD order body looks like this, with your signed values in place of the placeholders:

{
  "deferExec": false,
  "order": {
    "builder": "0x0000000000000000000000000000000000000000000000000000000000000000",
    "expiration": "YOUR_UNIX_SECONDS",
    "maker": "YOUR_DEPOSIT_WALLET_ADDRESS",
    "makerAmount": "5200000",
    "metadata": "0x0000000000000000000000000000000000000000000000000000000000000000",
    "salt": 479249096354,
    "side": "BUY",
    "signature": "YOUR_ORDER_SIGNATURE",
    "signatureType": 3,
    "signer": "YOUR_DEPOSIT_WALLET_ADDRESS",
    "takerAmount": "10000000",
    "timestamp": "YOUR_UNIX_MILLISECONDS",
    "tokenId": "YOUR_TOKEN_ID"
  },
  "orderType": "GTD",
  "owner": "YOUR_API_KEY",
  "postOnly": true
}

What do Polymarket order statuses mean?

delayed comes from markets that hold marketable orders briefly: a taker delay on selected crypto and finance Up or Down markets, and a configured delay on some sports markets. The order is pending and cannot be canceled during the delay, and it is rejected if balance, allowance or risk checks fail when the delay ends. The unified SDK reports a raw unmatched status as ok: false with the code unmatched, so check open orders before resubmitting.

In our checks on 3 October 2026, Bitcoin 5-minute and 15-minute Up or Down markets returned itode: true, Polymarket's taker delay flag, from the public GET /clob-markets/{condition_id} endpoint, and soccer and esports markets reported secondsDelay: 1 in the Gamma API.

Why was my Polymarket order rejected?

In the 0.12.0 source, tick and size errors have no dedicated SDK code and arrive as unknown with the original message, though the SDK checks the tick grid before signing. Rounding onto it is covered in the Polymarket tick size guide. An order timed out error, an HTTP 500 during bursts of orders from one account, never reached the book, and Polymarket says it can be safely resubmitted.

How do you place orders across venues?

Order vocabularies differ from venue to venue, so a bot that trades beyond Polymarket ends up maintaining several sets of rules. The Predictefy API builds orders server side across 15+ venues through one integration, and you sign each one in your own wallet or process, so Predictefy never holds your funds or keys. To rehearse an order flow before real money is involved, paper trading costs 0 credits on every plan.

Frequently Asked Questions