Skip to main content
POST
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.

Authentication

Use a scoped API token with HMAC signing and the trading scope.

Signed order rules

For client-signed orders, signature and signatureType are both required. They must either both be present or both be omitted. Omission is accepted only for delegated server signing with an HMAC token carrying delegated_signing. nonce is required and must be the numeric value 0. expiration may be omitted; omission is signed as zero. If supplied, it must represent zero, for example "0". Non-zero expiration is not supported. Amounts are integer raw units with 6 decimals. makerAmount must be at least 100 raw units. For GTC and FAK orders, price is required, must be between 0.01 and 0.99, and may have at most three decimal places. The collateral equation must be exact. price × contracts must be an integer raw-unit amount, without rounding. postOnly is supported only for GTC 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 with the message "Profile ID does not match the order owner".
  • Delegated signing (unsigned order, delegated_signing scope, server wallet sub-account): send the target profile ID as both onBehalfOf and ownerId. The server normalizes ownerId to that target 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).
  • Signer does not match - you should use embedded address for smart wallet: your profile is in smart-wallet trading mode, which self-signed API orders can’t satisfy. Switch to EOA mode. See Trading wallet mode.

Delegated signing

Partners place orders for a managed sub-account by setting body onBehalfOf to its profile ID. A client-signed order requires trading; the target must belong to the authenticated partner. With both trading and delegated_signing, partners may instead omit both signature and signatureType. The request must still include the target profile ID as both onBehalfOf and ownerId. The server signs using a Privy server wallet linked to that profile, replaces maker and signer with that wallet address, and normalizes ownerId to the target. See Authentication.

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.

Errors

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
integer
required

Required profile ID of the order owner. For delegated signing, send the target profile ID as both ownerId and onBehalfOf.

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

Optional owner-scoped uniqueness and deduplication key. The submitted value is limited to 128 characters, then trimmed; blank values are rejected. Reuse returns 409 rather than replaying an earlier response.

Maximum string length: 128
Example:

"client-order-001"

onBehalfOf
integer

Managed profile ID for partner placement. Requires trading and a partner relationship; unsigned delegated placement also requires delegated_signing.

Required range: x >= 1
Example:

12345

timestamp
integer

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
integer

Optional maximum order age in milliseconds, up to 10000. If omitted, the API default applies. A supplied window without timestamp uses server receive time.

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 accepted. It may be resting, delayed, matched, settled, canceled by STP, or accepted with a settlement failure reported in execution.

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