API reference / Terminal routes and batch orders

Batch orders

Terminal routes and batch orders. Generated from the OpenAPI document the services export (/openapi.json).

Samples use the placeholders YOUR_API_KEY and YOUR_ACCOUNT_ID. Paste a sandbox key (twsk_…) to fill them in and to use Try it. It stays in this browser tab and is only sent to the sandbox, never to the live API.

Sandbox key

Sandbox account id

Try it is off in this build: No sandbox URL is configured for this build of the docs.

POST `/v1/orders`

Batch orders Auth: X-API-Key

Send one order to several accounts at once (at most 20 legs). Every leg inherits defaults and may override any of it, including with a falsy value (slippage: 0 means zero). Fields are snake_case: symbol, operation (buy, sell, buyLimit, sellLimit, buyStop, sellStop, buyStopLimit, sellStopLimit), volume, price, slippage, stop_loss, take_profit, stop_limit_price, expiration, comment, expert_id and, on the leg, account_id. results mirrors orders one for one. Leg status: filled (the broker accepted), rejected (the broker refused; retcode says why), invalid (the terminal refused the request), unavailable (terminal up but not trading), unreachable (no terminal), timeout (unknown: it may have executed, including when the broker's reply was lost; reconcile or replay with the same Idempotency-Key, never blind-retry). Validation is all-or-nothing, execution is not. Errors: 400 invalid_batch / unknown_account / unreachable_account (with require_reachable), 401, 403 (read-only key), 409 idempotency_in_flight, 422 idempotency_key_reused, 429 rate_limited (60 batches a minute per organisation, with Retry-After), 503 idempotency_unavailable. Idempotency-Key (at most 128 characters) replays the stored response for 15 minutes with idempotent_replay: true; each leg also carries its own derived key, so a retry never double-fills a leg that already executed. Every leg is in its account's audit trail.

Responses

200 Successful Response
422 Validation Error · HTTPValidationError

Errors (common for this kind of call; every error uses one envelope)

curl

curl -sS -X POST 'https://api.tickwire.io/v1/orders' \
  -H 'X-API-Key: YOUR_API_KEY'

Python

from tickwire import Tickwire

with Tickwire("https://api.tickwire.io", "YOUR_API_KEY") as tw:
    result = tw.request(
        "POST",
        "/v1/orders",
        idempotency_key="my-request-1",
        reason="why you are doing this",
    )
    print(result)

TypeScript

import { TickwireClient } from "@tickwire/sdk";

const tw = new TickwireClient({ baseUrl: "https://api.tickwire.io", token: "YOUR_API_KEY" });
const result = await tw.request("POST", "/v1/orders", {
  idempotencyKey: "my-request-1",
  reason: "why you are doing this",
});
console.log(result);
tw.close();

Try it in the sandbox

Try it is off in this build of the docs: no sandbox URL is configured. The samples above work against the sandbox with your sandbox key.

POST `/v1/orders/close`

Batch close Auth: X-API-Key

Close by selector (or explicit tickets) across several accounts at once (at most 20 accounts, 20 orders each; more come back skipped). Each account entry is a selector (symbol required, * for all, typed literally; symbol_match exact or base to accept broker suffixes like .sd / m; side long, short or any; kind position (default), pending or any; magic) or an explicit tickets list, never both. volume closes part of each matched position. Accounts run concurrently; the tickets of one account run in sequence. Account status: closed, partial, failed, nothing_matched (not an error), unavailable / unreachable / invalid (the lookup failed, so nothing is known), timeout (orders may have closed). Ticket status: closed, rejected, invalid, unavailable, unreachable, timeout (may have closed), skipped (never sent). A ticket that was already gone counts as closed with a message saying so. Errors and Idempotency-Key work as on POST /v1/orders.