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 whichever connected broker it goes to.

​
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

By default Anthid mints the 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 mint the intent’s identifier themselves and name it on the create. Anthid uses it as the intent’s own, so every amendment, cancellation, order update, and fill under that intent carries an identifier the sender already held before the request went out, including any that arrive before the response does. Where several of your systems trade the same account, it is what makes an order attributable to the one that placed it. A lost response is also what the Idempotency-Key header is for: a retry under the same key is answered with the intent the first request made, rather than placing a second order. See Request correlation and retries.

​
Where to see them

Anthid serves intents from two places, each built for a different question. Recent operational state comes from the Intents API. Completed intents can remain there while archival and cleanup finish. Presence in this list does not mean an order is still actionable; read its outcome and resulting order state. 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. When an intent reaches a terminal state, its action chain is archived asynchronously. Cleanup waits for the ledger to confirm the archive. The historical record is retained for six years with its attribution, while the plan controls the API query window.