Get latest intent action
Returns the latest action recorded for an intent. An optional trading account ID narrows the lookup to that account. The response includes the submitted symbol, the resolved instrument, dispatch state, and the separate broker runtime_status. A null runtime status means the broker has not reported one.
Authorizations
Bearer authentication header of the form Bearer <token>, where <token> is your auth token.
Headers
Organization ID required for service-account credentials
Path Parameters
Intent ID
Query Parameters
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.
CREATE, REPLACE, CANCEL 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].
- Option 1
- Option 2
- Option 3
- Option 4
- Option 5
- Option 6
- Option 7
UNSPECIFIED, BUY, SELL, SELL_SHORT UNSPECIFIED, LIMIT, MARKET, FILL_OR_KILL, LIMIT_ON_OPEN, LIMIT_ON_CLOSE, MARKET_ON_OPEN, MARKET_ON_CLOSE, STOP, STOP_LIMIT, TRAILING_STOP 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.
UNSPECIFIED, SMART, AMEX, ARCA, BATS, BATY, EDGA, EDGX, NSDQ, NYSE 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.
API_KEY, USER, SERVICE 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.
UNSPECIFIED, DAY, IMMEDIATE_OR_CANCEL, GOOD_TILL_CANCEL, AT_OPEN, AT_CLOSE, FILL_OR_KILL, EXT 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.
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.
PENDING, OPEN, PARTIALLY_FILLED, FILLED, CANCELLED, REJECTED Latest dispatch state for this action, newest outbox entry first.
PENDING, PROCESSING, SENT, FAILED