Skip to main content
GET
Get latest intent action

Authorizations

Authorization
string
header
required

Bearer authentication header of the form Bearer <token>, where <token> is your auth token.

Headers

x-organization-id
string<uuid> | null

Organization ID required for service-account credentials

Path Parameters

intent_id
string<uuid>
required

Intent ID

Query Parameters

trading_account_id
string<uuid>

Trading account the intent must belong to

Response

Latest intent action retrieved

An intent action together with how far its dispatch has got.

The action record is the immutable thing that was asked for; the state is the newest entry in its outbox lineage, so it moves as the action is picked up and published. They live in separate tables (the action is appended once, the state is appended per transition) and are joined here rather than leaving callers to correlate two endpoints.

state is None when no outbox row exists yet for the action. That is a real and momentary condition: the action and its first outbox row are written in one transaction, so it only shows up for a read racing that commit, and it is not the same as Pending.

runtime_status is the other half of the answer, and the one callers usually want: state says how far the platform got in handing the order to a broker, and stays SENT forever afterwards. It says nothing about whether the order filled. runtime_status is what the broker reports back.

account_id
string<uuid>
required
action_type
enum<string>
required
Available options:
CREATE,
REPLACE,
CANCEL
created_at
string<date-time>
required
instrument
object
required

What symbol resolved to, when the intent was created.

Resolved once, at the create, by the same lookup the controls were evaluated against, and copied unchanged onto every replace and cancel under the intent. It is what the broker adapter places the order in, so nothing downstream resolves the symbol a second time and risks a different answer across a catalogue sync.

Mandatory, and deliberately without serde(default), for the reason BrokerOrder::instrument gives: while it could be absent, every reader had to decide what absent meant, and the tempting answer - an equity - is the assumption this field exists to remove. A command that predates the field fails to deserialize instead.

Stored as JSON wherever the record is stored, because the sum type cannot be flattened into columns without inventing a column per variant. In Postgres that is a JSONB column; see the sqlx impl on [Instrument].

intent_id
string<uuid>
required
order_side
enum<string>
required
Available options:
UNSPECIFIED,
BUY,
SELL,
SELL_SHORT
order_type
enum<string>
required
Available options:
UNSPECIFIED,
LIMIT,
MARKET,
FILL_OR_KILL,
LIMIT_ON_OPEN,
LIMIT_ON_CLOSE,
MARKET_ON_OPEN,
MARKET_ON_CLOSE,
STOP,
STOP_LIMIT,
TRAILING_STOP
order_venue
enum<string>
required

Where an order is commanded to go.

Deliberately not the same question as Instrument::venue [blocked], which says where an instrument is listed. AAPL is listed on one exchange and routable to several; the listing is a fact about the security that the instruments catalogue owns, and this is an instruction the caller gives per order. Two orders on the same instrument from the same account can carry different values here, which is why this lives on the order and not on the instrument.

Only equities give the choice any width. Every other asset class trades at exactly one venue - ESZ5 means nothing away from CME - so for those the instrument already determines the destination and [Self::Smart] is the honest answer: there is nothing to choose between.

This was RouteStrategy, which named the mechanism rather than the thing, and read as though the platform routed every asset class this way.

Unspecified is what an unset column and a zero-valued proto field read back as, the same role it plays on Broker [blocked] and AssetClass [blocked]. It is not a destination: an order carrying it has not been told where to go.

Available options:
UNSPECIFIED,
SMART,
AMEX,
ARCA,
BATS,
BATY,
EDGA,
EDGX,
NSDQ,
NYSE
organization_id
string<uuid>
required
principal_id
string
required
principal_type
enum<string>
required

Class of credential behind an instruction.

An order placed with an organization's API key, one placed by a person signed in to the dashboard, and one placed by an Anthid service acting on the organization's behalf are three different claims once an order is disputed. Recording only the organization cannot tell them apart.

Available options:
API_KEY,
USER,
SERVICE
quantity
string
required
received_at
string<date-time>
required
request_id
string
required
seq
integer<int64>
required
symbol
string
required
idempotency_key
string | null
limit_price
null | string
source_ip
string | null
stop_price
null | string
strategy_id
string<uuid> | null

The caller's strategy this command belongs to, if it named one.

What a strategy is belongs to the caller - one run, one cycle away from a target position and back - and the platform only groups by it. Set on the create and copied unchanged onto every replace and cancel under the intent, so every command of one intent names the same strategy and every order it produces is summed under it.

serde(default) because this record is stored as a JSON payload, and payloads written before the field existed carry no key for it.

time_in_force
null | enum<string>
Available options:
UNSPECIFIED,
DAY,
IMMEDIATE_OR_CANCEL,
GOOD_TILL_CANCEL,
AT_OPEN,
AT_CLOSE,
FILL_OR_KILL,
EXT
principal_name
string | null

Who placed it, by name, as it read when the action was taken.

A sibling of the action rather than a field on it, for the same reason state is: IntentActionRecord is the payload dispatched to the broker path, and which person pressed the button is no part of an order. This is the supervisory read, and the only place the name is wanted.

None is the ordinary case for an API key or a service, neither of which has a person to name, and for anything recorded before the name was captured. Callers fall back to the credential class rather than inventing a label.

runtime_status
null | enum<string>

Where the intent stands at the broker.

Per intent rather than per action: an intent has one live order at a time, and a replace does not give the superseded action its own outcome. Every action in a chain therefore reports the same value, which is the truthful rendering of "what became of what I asked for".

None means the broker has not reported on it yet. That covers an order accepted moments ago and still in flight, and it is deliberately not collapsed into PENDING: a null says the platform has heard nothing, where PENDING is the broker saying it has the order and has not worked it. Callers that need one value can treat null as pending; ones that are watching for a stuck order need to tell them apart.

Available options:
PENDING,
OPEN,
PARTIALLY_FILLED,
FILLED,
CANCELLED,
REJECTED
state
null | enum<string>

Latest dispatch state for this action, newest outbox entry first.

Available options:
PENDING,
PROCESSING,
SENT,
FAILED