curl --request POST \
--url https://api.trysoar.com/v1/orders \
--header 'Content-Type: application/json' \
--header 'X-API-KEY: <api-key>' \
--data '
{
"ticker": "ANTHROPIC-VALUATION-26Q3-1.05T",
"outcome": "yes",
"side": "buy",
"price": 42,
"qty": 100,
"time_in_force": "gtc",
"client_order_id": "quoter-a-0007"
}
'{
"order_id": "<string>",
"ticker": "<string>",
"market_id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"event_ticker": "<string>",
"outcome": "yes",
"side": "buy",
"price": 50,
"qty": 1,
"remaining_qty": 1,
"filled_qty": 1,
"status": "accepted",
"time_in_force": "gtc",
"created_at": "2023-11-07T05:31:56Z",
"updated_at": "2023-11-07T05:31:56Z",
"client_order_id": "<string>",
"reserved_cents": 1,
"spent_cents": 2
}{
"code": "invalid_enum_value",
"error": "side must be one of \"buy\", \"sell\", got \"hold\""
}{
"code": "unauthenticated",
"error": "API key or bearer token required"
}{
"code": "forbidden_scope",
"error": "api key lacks scope: trade"
}{
"code": "invalid_request_body",
"error": "<string>",
"details": "<string>"
}{
"code": "insufficient_balance",
"error": "insufficient balance"
}{
"code": "rate_limited",
"error": "rate limited (per-api-key)"
}{
"code": "result_unknown",
"error": "engine result unknown"
}Place an order
Matching has already happened when this returns: the response carries
the engine’s own filled_qty, remaining_qty, and a status derived
from what actually happened. An ioc or fok that filled nothing comes
back canceled.
Size the order in shares (qty) or in cash (budget_cents),
never both. A budget order is a taker buy — “spend $50.00 on yes” — that
the engine sizes against the live book inside the match step, fees
included, with price as your worst-price bound; see
CreateOrderRequest.budget_cents for the full semantics.
client_order_id is your idempotency key and is scoped to your user. The
gateway derives the engine’s command_id and the order_id
deterministically from it, so re-sending the same one returns the same
order — which is exactly what makes it the safe response to a
result_unknown 503.
curl --request POST \
--url https://api.trysoar.com/v1/orders \
--header 'Content-Type: application/json' \
--header 'X-API-KEY: <api-key>' \
--data '
{
"ticker": "ANTHROPIC-VALUATION-26Q3-1.05T",
"outcome": "yes",
"side": "buy",
"price": 42,
"qty": 100,
"time_in_force": "gtc",
"client_order_id": "quoter-a-0007"
}
'{
"order_id": "<string>",
"ticker": "<string>",
"market_id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"event_ticker": "<string>",
"outcome": "yes",
"side": "buy",
"price": 50,
"qty": 1,
"remaining_qty": 1,
"filled_qty": 1,
"status": "accepted",
"time_in_force": "gtc",
"created_at": "2023-11-07T05:31:56Z",
"updated_at": "2023-11-07T05:31:56Z",
"client_order_id": "<string>",
"reserved_cents": 1,
"spent_cents": 2
}{
"code": "invalid_enum_value",
"error": "side must be one of \"buy\", \"sell\", got \"hold\""
}{
"code": "unauthenticated",
"error": "API key or bearer token required"
}{
"code": "forbidden_scope",
"error": "api key lacks scope: trade"
}{
"code": "invalid_request_body",
"error": "<string>",
"details": "<string>"
}{
"code": "insufficient_balance",
"error": "insufficient balance"
}{
"code": "rate_limited",
"error": "rate limited (per-api-key)"
}{
"code": "result_unknown",
"error": "engine result unknown"
}Authorizations
Per-user API key. Create and revoke keys from your SOAR account settings. A revoked key stops working within 60 seconds.
Body
Supplying both ticker and market_id is 400 conflicting_identifiers
rather than a guessed winner — a caller that sends two identifiers does
not know which one it means, and guessing on a trading request is the
wrong kind of helpful. The same rule sizes the order: exactly one of
qty (shares) or budget_cents (cash), and both at once is
400 invalid_budget.
Which side of the market. Your position is in this outcome.
unknown is emitted only for a stored value this API version does not
recognise (corruption, or an encoding added after your client was
generated). It is declared so one bad row cannot fail the whole page;
treat it as unparseable data rather than a fourth outcome.
yes, no, unknown See Outcome for when unknown appears.
buy, sell, unknown Limit price in whole cents, for the outcome you named. On a budget order this is your worst acceptable per-share price — a pure slippage bound; fills execute at the resting prices, which may be better.
1 <= x <= 99Your idempotency key: 1–64 printable ASCII characters, unique per
user (two users may safely use the same value). Re-sending the same
one returns the same order rather than placing a second, which is
what makes it the correct response to a result_unknown 503.
1 - 64The market, by ticker. Send this or market_id, not both.
The market, by UUID. Send this or ticker, not both.
Whole shares. Send this or budget_cents, not both — an order
is denominated in shares or in cash, never both at once.
x >= 1A budget-denominated taker buy: "spend this many cents" instead
of "buy this many shares". The engine sizes the order against the
live book inside the match step, spending up to
min(budget_cents, your available cash) including taker fees —
there is no client-side dollars→shares conversion, so the budget is
consumed exactly (to within one share at your price bound).
Requires side: buy and time_in_force ioc or fok — a budget
order never rests, because its derived size is only meaningful
against the book it was sized on. fok fills the full affordable
size or rejects 422 budget_not_fillable when the book cannot
absorb the budget within your price bound; ioc executes whatever
is eligible and stops. The response's qty/filled_qty carry the
engine-derived executed size and spent_cents the exact realized
cost.
x >= 1Defaults to gtc. Budget orders must be ioc or fok.
gtc, ioc, fok, unknown Response
The engine applied the order.
Decimal digits in a string. It is FNV-derived and routinely exceeds 2^53, so a JSON number would be silently rounded by any JavaScript client and you would then cancel an order that does not exist.
^[0-9]{1,20}$This market's ticker.
The parent event's ticker — the prefix this market's ticker begins with.
Which side of the market. Your position is in this outcome.
unknown is emitted only for a stored value this API version does not
recognise (corruption, or an encoding added after your client was
generated). It is declared so one bad row cannot fail the whole page;
treat it as unparseable data rather than a fourth outcome.
yes, no, unknown See Outcome for when unknown appears.
buy, sell, unknown Your limit price in whole cents, for your own outcome.
1 <= x <= 99Original size in shares.
x >= 0x >= 0x >= 0accepted is a transient projection state visible only on reads,
while the durable state catches up. A create or amend response never
returns it: its status is derived from what the engine actually did.
accepted, open, partially_filled, filled, canceled, expired gtc rests until filled or canceled. ioc fills what it can
immediately and cancels the rest. fok fills entirely or not at all.
Omitted means gtc — an order that would silently become ioc dies the
moment it fails to cross.
gtc, ioc, fok, unknown On a read, when the engine sequenced the order. On a create or
amend response, the gateway's submit instant instead — the engine's
reply carries no timestamp, and the authoritative one is only visible
to the projection. The two are within a millisecond, but they are not
the same clock: re-sending an idempotent client_order_id returns the
same order with a fresh created_at. Key on order_id, not on this.
Echoed on the create response when you supplied one. Not stored,
so it is absent from every read (GET /orders, GET /orders/{order_id}) — keep your own mapping. order_id is derived
deterministically from it, so re-sending the identical create is
also a safe way to recover the id.
64Cash locked by this order. Present on reads only — a create or
amend response omits it, because the engine reports the caller's
account-wide reserve there rather than this order's share, and one
field name cannot mean both. For the account-wide figure use
reserved_cents on /portfolio/balance.
x >= 0Present only on the create response of a budget order: the exact
realized cash cost of the execution — fill flow plus taker fees,
cent for cent what left your balance. Absent on qty orders and on
every read (the projection does not store it); reconcile historical
executions against /portfolio/fills. On a budget order the
executed size is qty (= filled_qty), so spent_cents / qty is
your realized average cost per share, fees included.
x >= 1Was this page helpful?