Orders - Hit Documentation

Order endpoints require API key authentication. See Authentication for HMAC signing.

Order Model

Hit accepts low-level order payloads built from outcome token amounts.

Field	Required	Description
`salt`	Yes	Unique numeric string
`taker`	Yes	Usually `0x0000000000000000000000000000000000000000`
`tokenId`	Yes	Outcome token ID from market data
`makerAmount`	Yes	Amount supplied by the maker, in 6-decimal base units
`takerAmount`	Yes	Amount requested from the taker, in 6-decimal base units
`expiration`	Yes	Unix timestamp seconds, or `0`
`side`	Yes	`0` for buy, `1` for sell
`orderType`	Yes	`GTC`, `FOK` or `FAK`
`feeRateBps`	Client-signed only	Must match the market `orderFeeRateBps`
`signature`	Optional	Include for client-signed orders; omit when using server-side session signer
`nonce`	Optional	Client-signed orders only: the nonce the order is signed over. `0` when omitted
`idempotencyKey`	Optional	UUID v4 used to deduplicate repeated submission of the same logical order
`postOnly`	Optional	Maker-only GTC order; rejected if it would cross the book

Do not send priceUint. The server sets it, and the request validator rejects a body that carries it. Amounts use 6 decimals:

1 USDC = 1000000
1 share = 1000000

For limit orders:

Side	Meaning
Buy (`side: 0`)	`makerAmount` is USDC, `takerAmount` is shares, price = `makerAmount / takerAmount`
Sell (`side: 1`)	`makerAmount` is shares, `takerAmount` is USDC, price = `takerAmount / makerAmount`

Limit order prices must be valid multiples of the market tickSize.

Client-Signed Orders

Maker and signer are both your wallet, and the signature type is 0. maker, signer and signatureType are part of the signed message but are not sent in the body: Hit sets them from your account. See Place a Client-Signed Order.

Place an Order

TypeScript
Python
Rust

import { createHmac, randomBytes } from "node:crypto";

type JsonObject = Record<string, unknown>;

function units(value: number) {
  return Math.round(value * 1_000_000).toString();
}

function sign(secret: string, timestamp: string, method: string, path: string, body = "") {
  return createHmac("sha256", secret)
    .update(`${timestamp}${method.toUpperCase()}${path}${body}`)
    .digest("hex");
}

async function request(method: string, path: string, body?: JsonObject) {
  const fullPath = `/api/v1${path}`;
  const timestamp = Date.now().toString();
  const bodyText = body ? JSON.stringify(body) : "";

  const response = await fetch(`https://hit.com${fullPath}`, {
    method,
    headers: {
      "Content-Type": "application/json",
      "hit-api-key": process.env.HIT_API_KEY!,
      "hit-signature": sign(process.env.HIT_API_SECRET!, timestamp, method, fullPath, bodyText),
      "hit-timestamp": timestamp,
      "hit-passphrase": process.env.HIT_API_PASSPHRASE!,
    },
    body: bodyText || undefined,
  });

  if (!response.ok) {
    throw new Error(`${response.status}: ${await response.text()}`);
  }

  return response.json() as Promise<unknown>;
}

const order = await request("POST", "/orders", {
  salt: BigInt(`0x${randomBytes(32).toString("hex")}`).toString(),
  taker: "0x0000000000000000000000000000000000000000",
  tokenId: process.env.HIT_TOKEN_ID!,
  makerAmount: units(31), // USDC
  takerAmount: units(50), // shares
  expiration: 0,
  side: 0,
  orderType: "GTC",
});

console.log(order);

import hashlib
import hmac
import json
import os
import secrets
import time

import requests


def units(value: float) -> str:
    return str(round(value * 1_000_000))


def sign(secret: str, timestamp: str, method: str, path: str, body: str = "") -> str:
    message = f"{timestamp}{method.upper()}{path}{body}"
    return hmac.new(secret.encode(), message.encode(), hashlib.sha256).hexdigest()


def request(method: str, path: str, payload: dict | None = None):
    full_path = f"/api/v1{path}"
    timestamp = str(int(time.time() * 1000))
    body = json.dumps(payload, separators=(",", ":")) if payload else ""

    response = requests.request(
        method,
        f"https://hit.com{full_path}",
        headers={
            "Content-Type": "application/json",
            "hit-api-key": os.environ["HIT_API_KEY"],
            "hit-signature": sign(os.environ["HIT_API_SECRET"], timestamp, method, full_path, body),
            "hit-timestamp": timestamp,
            "hit-passphrase": os.environ["HIT_API_PASSPHRASE"],
        },
        data=body or None,
        timeout=10,
    )
    response.raise_for_status()
    return response.json()


order = request(
    "POST",
    "/orders",
    {
        "salt": str(secrets.randbits(256)),
        "taker": "0x0000000000000000000000000000000000000000",
        "tokenId": os.environ["HIT_TOKEN_ID"],
        "makerAmount": units(31),
        "takerAmount": units(50),
        "expiration": 0,
        "side": 0,
        "orderType": "GTC",
    },
)

print(order)

use hmac::{Hmac, Mac};
use reqwest::blocking::Client;
use serde_json::{json, Value};
use sha2::Sha256;
use std::env;
use std::time::{SystemTime, UNIX_EPOCH};

type HmacSha256 = Hmac<Sha256>;

fn timestamp_ms() -> String {
    SystemTime::now()
        .duration_since(UNIX_EPOCH)
        .expect("system clock before unix epoch")
        .as_millis()
        .to_string()
}

fn units(value: f64) -> String {
    (value * 1_000_000.0).round().to_string()
}

fn sign(secret: &str, timestamp: &str, method: &str, path: &str, body: &str) -> String {
    let message = format!("{}{}{}{}", timestamp, method.to_uppercase(), path, body);
    let mut mac = HmacSha256::new_from_slice(secret.as_bytes()).expect("hmac accepts any key");
    mac.update(message.as_bytes());
    hex::encode(mac.finalize().into_bytes())
}

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let client = Client::new();
    let path = "/api/v1/orders";
    let timestamp = timestamp_ms();
    let payload = json!({
        "salt": rand::random::<u128>().to_string(),
        "taker": "0x0000000000000000000000000000000000000000",
        "tokenId": env::var("HIT_TOKEN_ID")?,
        "makerAmount": units(31.0),
        "takerAmount": units(50.0),
        "expiration": 0,
        "side": 0,
        "orderType": "GTC"
    });
    let body = serde_json::to_string(&payload)?;
    let signature = sign(&env::var("HIT_API_SECRET")?, &timestamp, "POST", path, &body);

    let order: Value = client
        .post(format!("https://hit.com{}", path))
        .header("Content-Type", "application/json")
        .header("hit-api-key", env::var("HIT_API_KEY")?)
        .header("hit-signature", signature)
        .header("hit-timestamp", timestamp)
        .header("hit-passphrase", env::var("HIT_API_PASSPHRASE")?)
        .body(body)
        .send()?
        .error_for_status()?
        .json()?;

    println!("{order:#}");
    Ok(())
}

The examples buy 50 shares for 31 USDC, which is a 0.62 limit price.

Place a Client-Signed Order

To sign orders yourself:

Sign as your wallet: maker and signer are both your wallet’s address, and the signature type is 0.
Read the market with GET /markets/{id_or_slug} and pick the exchange from the market’s negRisk, not the event’s: the neg-risk exchange when it is true, the standard exchange otherwise.
Sign the complete EIP-712 Order with your wallet’s private key, over nonce 0 unless a nonce-stale refusal on that exchange has given you another one.
Send the order with API key authentication.

The signed message and the request body are not the same set of fields:

Field	Signed message	`POST /orders` body
`salt`, `taker`, `tokenId`, `makerAmount`, `takerAmount`, `expiration`, `feeRateBps`, `side`	Yes	Yes, with the same values
`maker`, `signer`, `signatureType`	Yes	No. Sending them returns `400`
`nonce`	Yes	Optional, with the same value. `0` when omitted
`signature`	No	Yes
`orderType`, `postOnly`, `idempotencyKey`	No	Yes

The examples add to the request and units helpers from Place an Order. Set HIT_MARKET_ID to the market and HIT_WALLET_PRIVATE_KEY to the private key of your HIT Wallet. Keep the key secret: anyone who has it controls your funds.

EIP-712 domain	Value
`name`	`Metawin CTF Exchange`
`version`	`1`
`chainId`	`8453` (Base)
`verifyingContract`	The exchange the order goes to: standard `0x71aCeb0c45f4d58a2549Dd21F1aDc8E86d2899EA`, neg-risk `0xDf667F94322fEcCa5D56a72Bb21a8a418b5EaC94`

The same exchange addresses are also served by GET /api/v1/contracts. A signed order whose nonce is not the one Hit holds for your wallet on that exchange is refused with 400, errorCode: "nonce-stale" and serverNonce, the nonce Hit holds. Sign the order again over serverNonce and send that value as nonce. Keep sending it with every order you sign for that exchange: an order sent without nonce is checked against 0. The standard and neg-risk exchanges keep separate nonces. The nonce only moves if your wallet itself calls incrementNonce() on the exchange. POST /orders/batch reports the same refusal for each entry it applies to, as that entry’s code together with its serverNonce.

TypeScript
Python

import { privateKeyToAccount } from "viem/accounts";

const EXCHANGE_DOMAIN = { name: "Metawin CTF Exchange", version: "1", chainId: 8453 };
const EXCHANGE_ADDRESS = "0x71aCeb0c45f4d58a2549Dd21F1aDc8E86d2899EA";
const NEG_RISK_EXCHANGE_ADDRESS = "0xDf667F94322fEcCa5D56a72Bb21a8a418b5EaC94";

const ORDER_TYPES = {
  Order: [
    { name: "salt", type: "uint256" },
    { name: "maker", type: "address" },
    { name: "signer", type: "address" },
    { name: "taker", type: "address" },
    { name: "tokenId", type: "uint256" },
    { name: "makerAmount", type: "uint256" },
    { name: "takerAmount", type: "uint256" },
    { name: "expiration", type: "uint256" },
    { name: "nonce", type: "uint256" },
    { name: "feeRateBps", type: "uint256" },
    { name: "side", type: "uint8" },
    { name: "signatureType", type: "uint8" },
  ],
} as const;

const account = privateKeyToAccount(process.env.HIT_WALLET_PRIVATE_KEY! as `0x${string}`);

// 1. You sign as your wallet: it is both maker and signer, with signature type 0.
const maker = account.address;
const signatureType = 0;

// 2. The market and its exchange, chosen by the market's negRisk.
const marketResponse = await fetch(`https://hit.com/api/v1/markets/${process.env.HIT_MARKET_ID!}`);
if (!marketResponse.ok) {
  throw new Error(`${marketResponse.status}: ${await marketResponse.text()}`);
}
const market = (await marketResponse.json()) as { tokenId1: string; orderFeeRateBps: number; negRisk: boolean };
const verifyingContract = (market.negRisk ? NEG_RISK_EXCHANGE_ADDRESS : EXCHANGE_ADDRESS) as `0x${string}`;

// 3. Sign the complete order: buy 50 shares of outcome 1 for 31 USDC.
const order = {
  salt: BigInt(`0x${randomBytes(32).toString("hex")}`).toString(),
  taker: "0x0000000000000000000000000000000000000000" as const,
  tokenId: market.tokenId1,
  makerAmount: units(31), // USDC
  takerAmount: units(50), // shares
  expiration: 0,
  nonce: 0, // after a nonce-stale refusal, its serverNonce
  feeRateBps: market.orderFeeRateBps,
  side: 0,
};

const signature = await account.signTypedData({
  domain: { ...EXCHANGE_DOMAIN, verifyingContract },
  types: ORDER_TYPES,
  primaryType: "Order",
  message: {
    salt: BigInt(order.salt),
    maker,
    signer: account.address,
    taker: order.taker,
    tokenId: BigInt(order.tokenId),
    makerAmount: BigInt(order.makerAmount),
    takerAmount: BigInt(order.takerAmount),
    expiration: BigInt(order.expiration),
    nonce: BigInt(order.nonce),
    feeRateBps: BigInt(order.feeRateBps),
    side: order.side,
    signatureType,
  },
});

// 4. Submit: the order fields, nonce included, plus signature and orderType. No maker, signer or signatureType.
const created = await request("POST", "/orders", { ...order, signature, orderType: "GTC" });

console.log(created);

from eth_account import Account

EXCHANGE_DOMAIN = {"name": "Metawin CTF Exchange", "version": "1", "chainId": 8453}
EXCHANGE_ADDRESS = "0x71aCeb0c45f4d58a2549Dd21F1aDc8E86d2899EA"
NEG_RISK_EXCHANGE_ADDRESS = "0xDf667F94322fEcCa5D56a72Bb21a8a418b5EaC94"

ORDER_TYPES = {
    "EIP712Domain": [
        {"name": "name", "type": "string"},
        {"name": "version", "type": "string"},
        {"name": "chainId", "type": "uint256"},
        {"name": "verifyingContract", "type": "address"},
    ],
    "Order": [
        {"name": "salt", "type": "uint256"},
        {"name": "maker", "type": "address"},
        {"name": "signer", "type": "address"},
        {"name": "taker", "type": "address"},
        {"name": "tokenId", "type": "uint256"},
        {"name": "makerAmount", "type": "uint256"},
        {"name": "takerAmount", "type": "uint256"},
        {"name": "expiration", "type": "uint256"},
        {"name": "nonce", "type": "uint256"},
        {"name": "feeRateBps", "type": "uint256"},
        {"name": "side", "type": "uint8"},
        {"name": "signatureType", "type": "uint8"},
    ],
}

account = Account.from_key(os.environ["HIT_WALLET_PRIVATE_KEY"])

# 1. You sign as your wallet: it is both maker and signer, with signature type 0.
maker = account.address
signature_type = 0

# 2. The market and its exchange, chosen by the market's negRisk.
market_response = requests.get(f"https://hit.com/api/v1/markets/{os.environ['HIT_MARKET_ID']}", timeout=10)
market_response.raise_for_status()
market = market_response.json()
verifying_contract = NEG_RISK_EXCHANGE_ADDRESS if market["negRisk"] else EXCHANGE_ADDRESS

# 3. Sign the complete order: buy 50 shares of outcome 1 for 31 USDC.
order = {
    "salt": str(secrets.randbits(256)),
    "taker": "0x0000000000000000000000000000000000000000",
    "tokenId": market["tokenId1"],
    "makerAmount": units(31),
    "takerAmount": units(50),
    "expiration": 0,
    "nonce": 0,  # after a nonce-stale refusal, its serverNonce
    "feeRateBps": market["orderFeeRateBps"],
    "side": 0,
}

signed = Account.sign_typed_data(
    account.key,
    full_message={
        "types": ORDER_TYPES,
        "primaryType": "Order",
        "domain": {**EXCHANGE_DOMAIN, "verifyingContract": verifying_contract},
        "message": {
            "salt": int(order["salt"]),
            "maker": maker,
            "signer": account.address,
            "taker": order["taker"],
            "tokenId": int(order["tokenId"]),
            "makerAmount": int(order["makerAmount"]),
            "takerAmount": int(order["takerAmount"]),
            "expiration": order["expiration"],
            "nonce": order["nonce"],
            "feeRateBps": order["feeRateBps"],
            "side": order["side"],
            "signatureType": signature_type,
        },
    },
)

# 4. Submit: the order fields, nonce included, plus signature and orderType. No maker, signer or signatureType.
created = request("POST", "/orders", {**order, "signature": "0x" + bytes(signed.signature).hex(), "orderType": "GTC"})

print(created)

The examples need viem for TypeScript and eth-account for Python.

Taker Delay

Some markets hold marketable orders for a short delay before matching. An order is marketable when it would match against an order already on the book, which makes it a taker order. Orders that rest on the book without matching are not delayed. Read the delay for any market from its speedBumpDelayMs field in market data.

Markets	Delay
Short-dated up/down markets	250ms

Read speedBumpDelayMs rather than hard-coding these values. The table shows where delays apply today, and more market types may get one in future. You cannot cancel an order while it is delayed. On the /user WebSocket namespace, an order-speed-bump-pending event tells you an order was delayed before matching. See WebSockets.

Retrying a Failed Order

POST /orders answers 503 when your order could not be signed, submitted or admitted. Nothing is created when it does, so re-sending the identical body cannot duplicate the order. Each of these 503s carries a Retry-After header and repeats the same figure in the body as retryAfterSeconds. A 503 whose error is CREDENTIAL_UNVERIFIABLE is not one of them. Your API key could not be checked, so the order was not attempted. It carries no Retry-After header: re-send the request, signed again with a fresh hit-timestamp. See Authentication Failures. Read error before errorCode. It is the discriminator, and only one of its two values carries an errorCode at all. SIGNING_UNAVAILABLE has no errorCode. It has four causes: the signing provider being unavailable, rate-limiting Hit or having no slot in Hit’s signing-admission queue; the request budget being exhausted before your order was submitted; the duplicate guard’s store being unavailable; and, on POST /orders/batch only, the locking infrastructure being unavailable. Three of those four — the request budget, the duplicate guard’s store, and the batch locking infrastructure — reach orders you signed yourself, so do not treat this status as something that only happens to orders Hit signs for you. Every batch takes its per-account lock whether or not anything in it needs signing. ORDER_ADMISSION_UNAVAILABLE carries an errorCode, one of six values:

`errorCode`	Meaning
`projection-stale`	The balance projection is not committing.
`balance-unknown`	Your balance has not been read from chain yet.
`balance-unprojected`	You have no projection row.
`collateral-source-unavailable`	The projection could not be queried at all.
`engine-busy`	The venue declined to admit the command at all.
`idempotency-unverifiable`	The venue could not check whether the idempotency key derived from your order had already been used.

The first four mean your collateral could not be read. engine-busy is a stronger statement than the others: the command was not decided, not recorded and not partially applied, because the venue was at one of its own internal bounds. idempotency-unverifiable means the duplicate check could not be answered, so the venue refused rather than risk a second live order for one key.

When you retry engine-busy or idempotency-unverifiable, re-send the identical body and do not change salt. The idempotency key is derived from the order’s contents, so a new salt is a different order and defeats the deduplication these codes exist to protect.

None of these means your order is invalid or your balance is insufficient. A genuinely insufficient balance is a 400, and retrying it will not help. POST /orders/batch reports the same six reasons per entry rather than as a 503. They arrive as that entry’s code inside a normal 201, with no Retry-After header, because other entries in the same request may have been created. That per-entry code set is open-ended: it is whatever the venue supplies for the entry, plus local fallbacks such as bad-request, internal-error, not-attempted, nonce-stale and order-archived. Do not assume the list is closed, and treat a value you do not recognise the way you treat internal-error. The batch route can still answer a request-level 503 with error: "SIGNING_UNAVAILABLE", and then nothing in the batch was created.

List Orders

curl 'https://hit.com/api/v1/orders' \
  -H 'hit-api-key: API_KEY' \
  -H 'hit-signature: SIGNATURE' \
  -H 'hit-timestamp: TIMESTAMP' \
  -H 'hit-passphrase: API_PASSPHRASE'

Filters:

Query	Description
`market`	Market UUID
`status`	`PENDING`, `EXECUTING`, `EXECUTED` or `REJECTED`; use the paginated endpoint for `CANCELLED`
`maker`	Maker wallet address
`marketName`	Case-insensitive partial market name
`sortBy`	Order sort field, default `created_at`
`order`	`ASC` or `DESC`

When status is omitted, GET /orders returns all non-cancelled statuses. Passing status=CANCELLED returns 400. Use GET /orders/paginated for paginated results and cancelled history. Its omitted-status default is active orders only (PENDING and EXECUTING). total is opt-in and capped; use cursor, hasMore and nextCursor for efficient deep pagination. Your own writes are already visible to these reads. A create or cancel this API has acknowledged appears on your next GET /orders, GET /orders/paginated or GET /orders/{id}, so you do not need to poll until it shows up or sleep between writing and reading. The read waits for the read model to catch up, bounded at 1 second by default. If that bound expires you still get an answer, built from what has been written so far, which may be missing your most recent write; re-read in that case rather than re-sending the write. GET /orders/events reads a different table and is outside this guarantee.

Cancel Orders

Request	Description
`POST /orders/{id}/cancel`	Cancel one order and return the updated order
`POST /orders/batch-cancel`	Cancel up to 50 order IDs
`POST /orders/cancel`	Cancel all orders in one market
`POST /orders/cancel-event`	Cancel all your orders across every market in one event
`POST /orders/cancel-all`	Cancel all your orders

Cancel one order:

await request("POST", `/orders/${process.env.HIT_ORDER_ID!}/cancel`);

Cancel a batch:

await request("POST", "/orders/batch-cancel", {
  orderIds: ["ORDER_UUID_1", "ORDER_UUID_2"],
});

Cancel all orders in a market:

await request("POST", "/orders/cancel", {
  market: "MARKET_UUID",
});

Cancel all orders in an event:

await request("POST", "/orders/cancel-event", {
  eventId: "EVENT_UUID",
});

Cancellations fail in different shapes depending on the route:

Request	Failure to handle
`POST /orders/{id}/cancel`, `POST /orders/cancel`	`503` with `error: "ORDER_ADMISSION_UNAVAILABLE"`, `errorCode: "engine-busy"` and a `Retry-After` header
`POST /orders/batch-cancel`	`500`, `408`, `503` or `409`, each with its own meaning
`POST /orders/cancel-all`, `POST /orders/cancel-event`	`207` when any order is still resting, `503` with an `outcome`, `409` or `422`, and unsuccessful entries in `results`

A 503 from POST /orders/{id}/cancel or POST /orders/cancel means nothing was cancelled, and you can re-send the identical request. On every one of these routes, a 503 whose error is CREDENTIAL_UNVERIFIABLE means your API key could not be checked and the request was not attempted, so nothing was cancelled. It carries no Retry-After header. Re-send the request, signed again with a fresh hit-timestamp. POST /orders/batch-cancel takes 1 to 50 version-4 UUIDs. It answers 500 when the venue replied with an error, 408 when no reply arrived within 30 seconds, 503 when the message broker failed, and 409 when another cancel-shaped batch is already in flight. None of the first three carries a Retry-After header or an errorCode. 408 and the broker’s 503 are lost-response cases: the orders may or may not have been cancelled, so re-read them before re-issuing. 409 is usually plain contention, but it is also returned when the lock service fails after your cancel was already published, so re-read on that one too rather than assuming nothing happened. POST /orders/cancel-all and POST /orders/cancel-event answer 200 when every order in scope is off the book and 207 when at least one is still resting. Both statuses carry the same body, so test for a 2xx rather than for one status. Read results, which has one entry per order the request covered. success says whether this request cancelled the order, so an entry can be false for an order that was already filled or cancelled. Decide from code:

type CancelResult = { orderId: string; success: boolean; code?: string; error?: string };

const { results } = (await request("POST", "/orders/cancel-all")) as { results: CancelResult[] };

const alreadyGone = ["state-conflict", "not-found"];

for (const entry of results) {
  if (entry.success || alreadyGone.includes(entry.code ?? "")) {
    continue; // off the book: nothing of yours is resting
  }
  if (entry.code === "unknown") {
    // The venue cannot say whether this cancel took effect. Read your open orders before re-sending.
    console.log("check", entry.orderId);
  } else {
    // Still resting: not-attempted, engine-busy, or a failure with no code.
    console.log("resting", entry.orderId);
  }
}

The request helper above returns only the body, and throws on any status that is not a 2xx. To tell 200 from 207, read response.status in your own helper before parsing the body. If a 207 carries no entry that is still resting, read your open orders before re-sending. A 503 whose error is ORDER_SERVICE_UNAVAILABLE carries an outcome: nothing-cancelled means the request never started and can be re-sent as it is; unknown means it may or may not have cancelled, so read your open orders first. One cause of nothing-cancelled is that the sweep could not read its list of your orders (order reads at capacity, no database connection free in time, or no way to confirm the list includes every order you were acknowledged for), so it acted on none of them. That 503 and the ORDER_ADMISSION_UNAVAILABLE one described under Admission Errors can both still carry results for orders the venue reached before the failure.

Migrating from the market fields

The cancel-all and cancel-event responses used to carry five market-level fields beside results: clearedMarkets, failedMarkets, notAdmitted, markets and cancelled. These fields were removed in markets-v0.0.149. The response now carries results alone, so a client that still reads any of those fields finds them absent. Read results and the status instead.

If you read	Read instead
`failedMarkets`, to decide what to retry	The entries in `results` that are still resting, as in the example above. Re-send for those, and read your open orders first for any marked `unknown`.
`notAdmitted`, for markets the venue refused	Entries in `results` with `code: "engine-busy"`. They carry no `retryAfterSeconds`.
`clearedMarkets`, `markets` or `cancelled`, to confirm the cancel worked	The status. `200` means every order in scope is off the book.
A `201` status, as success	Any 2xx. These routes answer `200` or `207`, not `201`.

results entries carry no market ID. If you need to know which market an order was in, use your own order records or GET /orders/{id}. Full response shapes are in the Orders API reference.

Positions and Activity

These endpoints also accept API key authentication:

Request	Description
`GET /markets/user-positions`	Current user positions
`GET /markets/value`	Position value for the current user, or for the wallet address in `user`
`GET /markets/user-activity`	User activity feed
`GET /markets/traded-count`	Number of markets traded
`GET /markets/redeemable-positions`	Resolved markets with positions you can redeem
`POST /markets/redeem-positions/batch`	Redeem one or more resolved market positions
`GET /markets/mergeable-positions`	Active markets where you hold both outcome legs
`POST /markets/merge-positions/batch`	Merge one or more complete Yes/No sets back into collateral
`GET /orders/events`	Active order book events across the platform, not scoped to you

​Order Model

​Client-Signed Orders

​Place an Order

​Place a Client-Signed Order

​Taker Delay

​Retrying a Failed Order

​List Orders

​Cancel Orders

​Migrating from the market fields

​Positions and Activity

Order Model

Client-Signed Orders

Place an Order

Place a Client-Signed Order

Taker Delay

Retrying a Failed Order

List Orders

Cancel Orders

Migrating from the market fields

Positions and Activity