Skip to main content
POST
Place a batch of signed orders (max 10)

Authorizations

X-Api-Key
string
header
required

Partner / integrator key — format ps_live_<keyId>_<secret>. Partner keys are issued by PredictStreet; a user can also create keys bound to their own wallet from their account settings in the web app. Never ship to a browser. multi_wallet partners must additionally send X-User-Wallet: 0x<40-hex> on every authenticated request to declare the acting wallet. See the API keys guide for scope taxonomy, partner kinds, rate limits, and rotation procedure.

Headers

X-User-Wallet
string

Required for multi_wallet partners on every authenticated request; ignored for single_wallet. Declares the acting end-user wallet for this request — drives KYC checks, balances/positions/orders attribution, rate-limit buckets, and audit. Lower-cased server-side. Missing on a multi_wallet key → 401 api_key_user_wallet_required; malformed → 401 api_key_user_wallet_invalid. The on-chain CTFExchange/Vault contracts still verify EIP-712 signer ↔ vault binding, so loosening API-layer attribution is safe by construction.

Pattern: ^0x[a-fA-F0-9]{40}$
Example:

"0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb3"

Body

application/json
orders
object[]
required

1–10 orders, each identical in shape to the single POST /api/orders/place body. Processed sequentially in array order.

Required array length: 1 - 10 elements

Response

Per-order results, aligned to the request orders[] by index. Inspect each entry's success flag and status — a 201 batch can still contain REJECTED entries (e.g. bad_signature, maker_mismatch). An entry the exchange was too busy to take comes back REJECTED with code: journal_intent_not_durable and details.retryable: true: nothing was admitted for it, so resend that same signed order unchanged, under the same clientOrderId, shortly. The other entries keep their own results.

orderId
string
required

Server-side order id (UUID). Empty string when the order was rejected before it was recorded (validation, signature, fee or funds checks); an order the matching engine rejects after it was recorded comes back as REJECTED with its real id.

status
enum<string>
required

Lifecycle state at the moment of response. Note: a 201 response may carry status=REJECTED together with a populated code / message — partner SDKs MUST inspect the body, not just the HTTP code.

Available options:
PENDING,
OPEN,
FILLED,
CANCELLED,
REJECTED,
EXPIRED,
SETTLEMENT_FAILED
filledQty
string
required

Cumulative quantity filled at response time (decimal string).

remainingQty
string
required

quantity - filledQty (decimal string).

trades
object[]
required

Synchronous fills produced by IOC/FOK or aggressive LIMIT orders.

success
boolean
required

true when the order was accepted (status ≠ REJECTED); false for a per-order business reject. Convenience flag over status.

code
string

Reject reason code (insufficient_funds, invalid_amounts, market_not_open, bad_signature, order_signed_with_floor_notional, insufficient_position, …). Present when status=REJECTED. For order_signed_with_floor_notional the response body also carries a details object with signedMakerAmountWei + expectedCeilMakerAmountWei so the SDK can re-sign without recomputing the CEIL formula — see /errors/codes#order_signed_with_floor_notional-diagnostic-hints.

message
string

Human-readable explanation; pairs with code.

traceId
string

Correlation id for this request — quote it in support reports. On place-batch every entry carries the same value. Omitted (never null) when no trace is active. Error envelopes carry the same id as error.trace_id.

details
object

Structured rejection context; the shape depends on code. bad_signature carries recovered (the address your signature recovers to, null if it does not decode), expected_signer (the authenticated wallet) and platform_canonical_struct (the exact Order struct the platform hashed and verified) — diff it field by field against the struct you signed. order_signed_with_floor_notional carries signedMakerAmountWei + expectedCeilMakerAmountWei. Never rely on details being present — check before reading.

clientOrderId
string

Echo of the request clientOrderId (when supplied). Lets MM partners correlate the server-issued orderId to their own client-side handle without a follow-up GET /api/orders/{id}. Present on every shape (success, REJECTED, idempotent replay) when the request carried one. Also echoed on the order_placed and order_cancelled frames of the user_orders WebSocket channel.