Recorded before acknowledged: why an instruction and its execution fail independently

Anthid writes your instruction to a durable record before it tells you the instruction was accepted, and before it contacts a broker. That ordering is the rule the rest of the execution layer is built around. This article explains why it matters, what it rules out, and what it lets you answer on the day something goes wrong.

An instruction and its outcome fail independently

Most broker APIs give you one object. You send an order, and what comes back is both your request and the live state of that order at the venue. While that is convenient, it collapses two things that do not fail together. A broker can be unreachable. It can reject an order. It can acknowledge an order and then lose it. It can fill an order 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 begins only once the broker accepts cannot describe the moment in between, and it cannot answer the question a review asks first: what was attempted when nothing came back? Anthid keeps the two apart. An intent is what you asked for. An order is what came of it at the broker. The intent exists first, and it exists whether or not an order ever does.

What “recorded before acknowledged” means in practice

When you submit an intent, Anthid commits it to an append-only event stream in the same database transaction that queues it for execution. You receive a response only after that transaction commits.

curl https://api.anthid.com/v1/intents \
  -X POST \
  -H "x-api-key: <YOUR_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "trading_account_id": "<ACCOUNT_ID>",
    "command": {
      "type": "CREATE",
      "payload": {
        "symbol": "AAPL",
        "order_side": "BUY",
        "spec": {
          "Limit": { "price": "100.00", "quantity": "10", "time_in_force": "DAY" }
        }
      }
    }
  }'

{
  "intent_id": "019c0538-86f2-7c32-9c1e-6f79cbfdb7b4"
}

That response is a receipt for the record, not for the fill. It says three things: your controls allowed the instruction, the instruction is now durable, and the work to carry it to the broker is queued. It says nothing about execution yet, and it is not supposed to. See SENT is not FILLED for how execution is reported. Because the record and the queue entry are one transaction, there is no window in which an instruction is in flight but unrecorded. Either both exist or neither does. No order can reach a broker through Anthid without a record that says who asked for it.

The record cannot be rewritten

The instruction stream is append-only, and that is enforced by the database rather than by application code. A trigger rejects any attempt to update or delete a row. The application has no path to modify a recorded instruction, and neither does an ordinary database session. Corrections are not edits. A replace or a cancel is appended as a new, sequenced action against the same intent, carrying the credential that sent it. Amend an order twice and then pull it, and the intent holds four actions in order: the create, two replaces, and the cancel. Read them back with one call.

curl "https://api.anthid.com/v1/intents/<INTENT_ID>/actions" \
  -H "x-api-key: <YOUR_API_KEY>"

A REPLACE carries a complete order specification, not a patch. Fields left out of the replacement are not inherited from the original. The record keeps every version, so the history shows exactly what each amendment asked for, but a replace that names only a new price will not preserve the original quantity. See the Intents API.

What each record carries

A record is only useful in a dispute if it can say who, when, and from where. Every action carries:

Field	What it establishes
Resolved order payload	The instruction exactly as Anthid understood it
Action type and sequence	Create, replace, or cancel, and its position in the intent’s history
Credential	Which of your credentials sent it, and of what kind: an API key, a signed-in user, or an Anthid service acting for you
Client reference	Your own correlation identifier, carried unchanged through every later action
Request identifier	Ties the record to the single request that produced it
Arrival and write timestamps	When the request reached the edge, recorded separately from when the row was committed
Client address	The calling address as observed at the network edge, never from a caller-supplied header

Attribution is taken from the request every time and never inherited from the thing being changed. One credential cancelling what another credential placed is visible rather than hidden. That is the half of a disputed order that turns out to matter, and it cannot be reconstructed afterwards if it was not written at the time.

Refusals are recorded too

A record of what Anthid accepted is only half of what a supervisory review asks for. The other half is what it stopped. Submissions refused by your controls, by an entitlement, or by authorization are written to their own append-only stream with the same attribution and the submission exactly as it arrived. A controls refusal carries the specific limits that triggered, which is the same detail the caller received. The record is written independently of the transaction the order would have used, so a refusal cannot be lost to the same rollback that discarded the order.

curl "https://api.anthid.com/v1/intents/rejections?stage=CONTROLS&days=7" \
  -H "x-api-key: <YOUR_API_KEY>"

One case is worth stating plainly: an attempt to submit against an account your organization does not own is refused and recorded, with the credential behind it. The caller is told the account was not found. The record says what was tried.

What this lets you answer

Put the pieces together and the awkward questions get short answers. The broker never responded. The intent exists, its actions are recorded, and its dispatch state says how far the platform got. Nothing about the instruction depends on the broker having spoken. Two systems trade the same account and one of them placed something it should not have. The credential on the action says which one. The client reference says which run. An order was amended and nobody remembers what it originally said. The action chain holds every version in sequence. A limit blocked an order last Tuesday and someone wants to know why. The refusal record names the controls that fired, and the control change stream says who set them and when. A regulator asks two years from now. The instruction stream is retained for six years, with the attribution intact. See Compliance for the full retention model.

Why this makes the broker a setting

The same separation is what keeps the layer broker-agnostic. An intent is expressed in Anthid’s own terms and recorded that way. It is translated into a broker’s dialect only at routing time, which is after the record exists. So the instruction reads the same whether it goes to Alpaca or Lightspeed, and the record of it does not change when the account behind it does.

Intents

The model in detail: intents, actions, dispatch, and outcome.

Compliance

What is recorded, how it is protected, and how long it is kept.

Articles

Platform news

2026

Recorded before acknowledged: why an instruction and its execution fail independently

An instruction and its outcome fail independently

What “recorded before acknowledged” means in practice

The record cannot be rewritten

What each record carries

Refusals are recorded too

What this lets you answer

Why this makes the broker a setting

Intents

Compliance

​An instruction and its outcome fail independently

​What “recorded before acknowledged” means in practice

​The record cannot be rewritten

​What each record carries

​Refusals are recorded too

​What this lets you answer

​Why this makes the broker a setting

Intents

Compliance

An instruction and its outcome fail independently

What “recorded before acknowledged” means in practice

The record cannot be rewritten

What each record carries

Refusals are recorded too

What this lets you answer

Why this makes the broker a setting