Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.bayse.markets/llms.txt

Use this file to discover all available pages before exploring further.

Batch endpoints let you submit many orders, amendments, or cancellations against the API in a single HTTP request. They are designed for market makers re-quoting on multiple books, latency-sensitive strategies that need to fan out activity in lockstep, and scripts that rebalance positions across many markets at once.
Batch order endpoints are CLOB-only. AMM markets are rejected per-order with UNSUPPORTED_ENGINE since AMM orders execute instantly and cannot be batched against an order book.

​
Endpoints

OperationEndpointMax items per call
Place a batchPOST /v1/pm/orders/batch20 orders
Cancel a batchDELETE /v1/pm/orders/batch100 orders
Amend a batchPOST /v1/pm/orders/batch/amend20 orders
All three endpoints require write authentication (X-Public-Key, X-Timestamp, X-Signature). See Authentication.

​
Cross-market batches

Batches can span multiple markets and events in a single call.
  • Place — each item carries only outcomeId. The server resolves the parent market and event from the outcome, so a batch can mix orders across different events.
  • Cancel — each item is a bare orderId (UUID). The server looks up the owning market and enforces ownership before cancelling.
  • Amend — each item is (orderId, newPrice, newSize). The server resolves the market from the order and enforces ownership before applying the change.
You don’t need to group items by market or send one batch per book. One call handles the whole fan-out.

​
Per-order best-effort semantics

A batch is not all-or-nothing. Each item is evaluated independently, so one bad input does not roll back the rest of the batch.
  • A bad outcomeId, an AMM market, an insufficient balance, or a missing required field on one item fails just that item.
  • The other items continue to execute and return their normal success or failure outcomes.
  • The HTTP response is 200 OK whenever the batch was processed, even if some items failed. Inspect the summary and per-item success flags to know what landed.
{
  "engine": "CLOB",
  "results": [
    { "index": 0, "success": true,  "order": { "id": "...", "status": "open" } },
    { "index": 1, "success": false, "error": { "code": "INSUFFICIENT_BALANCE", "message": "..." } },
    { "index": 2, "success": true,  "order": { "id": "...", "status": "open" } }
  ],
  "summary": { "total": 3, "succeeded": 2, "failed": 1 }
}

​
Rate limiting

Batch calls are charged per item against your API key’s write rate-limit bucket — a 20-order place batch costs 20 write tokens, not 1.
  • The check runs after the batch body is bound, so an over-budget batch returns 429 Too Many Requests with a Retry-After header before any orders are placed upstream.
  • Sizing batches close to the cap will exhaust your write budget more quickly. If you submit at the cap continuously, you will be limited by your tier’s write throughput just as if you’d placed the orders one by one.
See Rate limits for tier limits.

​
Idempotency

Both endpoints accept an optional Idempotency-Key header. When set, a retry of the same (API key, key, method, path) within 24 hours replays the original response and sets Idempotent-Replayed: true on the response — useful for safe retries after a network blip or a 5xx.
  • The key must be 1–255 characters of [A-Za-z0-9_-] (UUIDs and ULIDs are good defaults).
  • A retry with the same key but a different request body is rejected with 422 Unprocessable Entity. Generate a fresh key for a different payload.
  • A concurrent retry — sent before the first request has finished — is rejected with 409 Conflict. Back off briefly and retry; once the first call completes you’ll either get the cached response (success or stable client error) or be allowed to re-execute (transient errors are not cached).
  • Transient errors are not cached: 5xx, 429, and 408 are excluded so you can recover by retrying after the underlying condition clears. Stable 2xx and 4xx responses are cached for the full 24-hour window.

​
Cancel-and-replace cycles

When re-quoting, the canonical pattern is three sibling batches in sequence:
  1. DELETE /v1/pm/orders/batch — cancel stale orders. Frees their locked USD (BIDs) and shares (ASKs) back to the wallet and balance sheet.
  2. POST /v1/pm/orders/batch/amend — modify in-place orders whose price or size moved. Uses the capacity just freed in step 1 for any size-up / price-up debits.
  3. POST /v1/pm/orders/batch — place brand-new orders for bands without an existing order to amend. Uses whatever capacity remains.
Each call returns before the next starts, so the funding state visible to step N+1 reflects step N’s effects. Amend is the natural middle step because it keeps time priority where possible — an in-place price/size tweak retains queue position at the same level, whereas a cancel + re-place always goes to the tail. See Order lifecycle for the underlying status transitions.

​
Choosing between single and batch endpoints

Use the single place and single cancel endpoints for ad-hoc trading and any AMM activity. Reach for batch when:
  • You’re a market maker re-quoting both sides of one or more books.
  • You need orders on multiple markets to land together (e.g. a hedged pair).
  • You’re cancelling a working set after a strategy switch and want one round-trip instead of N.
  • You need to shift multiple resting orders’ prices or sizes without giving up queue priority.
See Batch place orders, Batch cancel orders, and Batch amend orders for the request and response schemas.