Skip to main content
POST
Create Order
Before creating orders:
  1. Fetch market data via Get Market Details to get venue and token IDs
  2. Sign the order using EIP-712 with venue.exchange as verifyingContract
  3. Ensure you have token approvals set up
Order creation can be temporarily restricted during maintenance. In post_only, only orders with postOnly: true are accepted. In cancel_only or disabled, new orders return 425 Too Early with a trading-mode code. Check Maintenance Mode before sending orders.

Optional Fields

Receive Window

POST /orders supports optional receive-window controls for clients that want freshness checks on order submission. Send these fields at the top level of the request body, next to order, orderType, and marketSlug; never put them inside the EIP-712 signed order object.
Keep trading hosts NTP-synced. If the timestamp is too far in the future or older than the receive window, the API returns 425 Too Early. Do not retry the same signed payload after a receive-window 425; build and sign a fresh order. If the 425 body has a trading-mode code, refresh maintenance status instead.

Self-Trade Prevention

POST /orders can reject or cancel orders that would match against your own resting order on the same token.
With cancel_maker, matching continues against the remaining non-self liquidity, and limit orders still never execute past their limit price. Outcomes on the placement response:
  • A rejected taker (cancel_taker / cancel_both) returns settlementStatus: "CANCELED" with reason: "STP_TAKER_REJECTED".
  • A cancel_maker taker lists the canceled resting order IDs in stpMakerCancels and keeps its normal status (UNMATCHED when nothing else fills it); no reason is set.
stpPolicy is a top-level request field. Do not include it inside the EIP-712 signed order object.
SDK support. Self-trade prevention is available in the TypeScript, Python, Rust, and Go SDKs — pass the policy on order creation and read the outcome from the execution object on the response. See TypeScript, Python, Rust, and Go.
Where does ownerId come from? It is the id field returned by GET /profiles/me or GET /profiles/{address}. For partner sub-accounts, it is the profileId returned by POST /profiles/partner-accounts, or recovered with GET /profiles/partner-accounts.
ownerId must match the profile that owns the order (see Programmatic API — EOA flow):
  • Partner EOA + signed order + onBehalfOf: set both onBehalfOf and ownerId to the sub-account’s profileId. order.maker and order.signer must match that sub-account’s wallet. A mismatched ownerId returns 400"Profile ID does not match the order owner".
  • Delegated signing (unsigned order, delegated_signing scope, server wallet sub-account): the server fills in ownerId when it signs — omit the client signature per Delegated Signing below.
  • Trading as yourself (no onBehalfOf): ownerId is your own profile id (the SDK often fills this after fetching your profile).

Delegated Signing

Partners with the delegated_signing scope can omit signature and signatureType from the order object. The server signs the order using a Privy server wallet linked to the target sub-account and sets maker/signer to the server wallet address. See Authentication for details.

Execution Response

The response includes an execution object with settlement details:
DELAYED (taker delay). Some markets apply a short hold to marketable (taker) orders before the matching engine fills them. On such a market, a marketable order’s response returns immediately with settlementStatus: "DELAYED", matched: false, zero totalsRaw, and an eligibleAt timestamp — it does not block until the trade is mined. Track the outcome over subscribe_order_events (provisional MATCHED → terminal MINED / FAILED), correlating by clientOrderId / tradeEventId. postOnly orders are never delayed.

Authorizations

lmts-api-key
string
header
required

Scoped API token with HMAC-SHA256 signing. Requires three headers: lmts-api-key (token ID), lmts-timestamp (ISO-8601), lmts-signature (Base64-encoded HMAC). See Authentication docs for details.

Body

application/json

Order creation data including signature and order parameters

order
object
required

Order details including signature and amounts

ownerId
number
required

Profile ID of the order owner

Example:

12345

orderType
enum<string>
required

Order type (GTC=Good Till Cancelled, FAK=Fill And Kill, FOK=Fill Or Kill)

Available options:
FAK,
FOK,
GTC
Example:

"GTC"

marketSlug
string
required

Market identifier slug

Example:

"biden-vs-trump-2024"

postOnly
boolean

Reject the order if it would match immediately. Supported only for GTC orders.

Example:

true

clientOrderId
string

Client-provided idempotency key for order placement. If a duplicate is submitted, the server returns 409 Conflict.

Maximum string length: 128
Example:

"client-order-001"

onBehalfOf
number

Profile ID to place order on behalf of (partner flow). Requires an API token with trading scope and a partner relationship with the target profile.

Example:

12345

timestamp
number

Optional client-stamped order creation time, Unix ms epoch. Top-level request field; not part of the EIP-712 signed order payload.

Required range: x >= 0
Example:

1735689600000

recvWindow
number

Optional maximum accepted order age in milliseconds. Valid range: 1 to 10000. If omitted, no receive-window check is applied. Top-level request field; not part of the EIP-712 signed order payload.

Required range: 1 <= x <= 10000
Example:

1500

stpPolicy
enum<string>

Self-trade prevention policy. Top-level request field; not part of the EIP-712 signed order payload. Defaults to cancel_maker when omitted.

Available options:
cancel_both,
cancel_maker,
cancel_taker
Example:

"cancel_maker"

Response

Order successfully created and matched

order
object
required

Order details including slim market and owner

execution
object
required

Execution and settlement summary

makerMatches
object[]

Maker matches if order was matched immediately