Skip to main content
An intent is a request for Anthid to do something on a connected account: place an order, amend one, or withdraw one. It is Anthid’s record of what you asked for, kept separately from whatever the broker subsequently does about it. Most broker APIs collapse the two. You send an order, and the thing you get back is both the request and the live state of that order at the venue. Anthid keeps them apart, because they answer different questions and they do not live the same length of time.

​
Why the separation exists

An instruction and its outcome fail independently. A broker can be unreachable, reject an order, acknowledge it and then lose it, or fill it hours later. In every one of those cases your instruction was real, was authorized, and was acted on by the platform. A model where the record only begins once the broker accepts cannot describe the moment in between, and cannot answer what was attempted when nothing came back. Anthid records the intent before it contacts the broker, in the same operation that queues the work. The order record comes later, when there is something at the broker to record. See Compliance for the guarantees around that ordering. The separation is also what keeps the platform broker-agnostic. An intent is expressed in Anthid’s own terms and translated into each broker’s dialect at routing time. The intent reads the same whether it goes to Alpaca or Lightspeed.

​
What happens to an intent

Two separate things happen to an instruction, and an intent reports both. Dispatch is how far Anthid got in handing the instruction to the broker. It moves through four states. Dispatch stops changing once it reaches SENT or FAILED. It stays SENT afterwards no matter what the broker goes on to do. Outcome is what the broker did with the order that followed. It is reported alongside the dispatch state, and it keeps moving after dispatch has stopped.
SENT does not mean filled. It means Anthid passed the order to the broker and the broker accepted the handoff. Whether it then filled, partially filled, rested, or was rejected at the venue is the outcome, not the dispatch state.This is the single most common misreading of the model, and it matters: a dashboard or report that treats SENT as “done” will overstate what actually traded.
The distinction between “not yet reported” and PENDING is deliberate. The first says Anthid has heard nothing back; the second is the broker saying it has the order and has not worked it. Anything watching for a stuck order needs to tell them apart. For the exact quantity traded, read the resulting order. The outcome tells you where the order stands; filled quantity tells you how much of it happened.

​
Amendments build a history, not a replacement

An intent is opened by a create, and can carry later amendments and cancellations. Each command is added to the intent as a new, sequenced entry rather than overwriting the previous one. So the intent accumulates a history: what was instructed, in what order, and by whom. Nothing is lost when an order is amended twice and then pulled.

An amendment restates the whole order

A replace carries a complete replacement order, not a partial edit. Anything it does not name is not inherited from the original, so an amendment that changes only the price will not preserve the original quantity. This is worth knowing when reviewing how a system was built to amend orders.

​
Attributing an order to the system that sent it

Anthid mints its own identifier for an intent and returns it on the response, which makes it useless for identifying a request that is still in flight or one whose response was lost. For that, your systems can set their own reference on submission. Anthid records it before the request goes out, carries it unchanged through every amendment and cancellation under that intent, and returns it on the resulting order. Where several of your systems trade the same account, it is what makes an order attributable to the one that placed it.

​
Where to see them

Anthid serves intents from two places, each built for a different question. What is working right now comes from the live surface. It holds only the intents you can still act on, so a read returns the current state of your working orders without paging through everything that came before. What happened comes from the ledger. Every completed intent is kept there with its full instruction history, filterable and sortable, alongside the aggregate counts that reporting and reconciliation run on. An intent moves from the first to the second when its order reaches a terminal state: filled, cancelled, or rejected. Live reads stay fast because they only ever cover active work, and the historical record is retained for six years with the attribution intact, so a supervisory review can answer who instructed what years after the fact.