FruxonDocs
Agent NetworkTriggers

Ends a work item's wait now, as if its due time had come.

For an item WAITING at a WAIT stage. The stage's due exit applies at once — the item continues to the next (or named) stage, or, under `onDue: FAIL` / `DEAD`, fails the window or gives up — and its history records `OPERATOR_WAKE` with the optional reason. Returns 409 when the item is not waiting at a WAIT stage, including when its wait ended between the read and the write.

POST
/v1/tenants/{tenant}/triggers/{trigger}/ledger/items/{item}:wake

Authorization

Bearer
AuthorizationBearer <token>

JWT Authorization header using the Bearer scheme. Enter 'Bearer' [space] and then your token.

In: header

Path Parameters

trigger*string

The trigger identifier.

Formatuuid
item*string

The ledger item identifier.

Formatuuid
tenant*string

The tenant identifier

Request Body

Optional operator note recorded on the transition.

reason?string|null

Operator note recorded on the transition.

Lengthlength <= 4000
[key: string]?never

Response Body

curl -X POST "https://api.fruxon.com/v1/tenants/string/triggers/497f6eca-6276-4993-bfeb-53cbbbba6f08/ledger/items/497f6eca-6276-4993-bfeb-53cbbbba6f08:wake" \  -H "Content-Type: application/json" \  -d '{}'
{
  "id": "00000000-0000-0000-0000-000000000000",
  "ledgerId": "00000000-0000-0000-0000-000000000000",
  "itemKey": "string",
  "label": "string",
  "stageId": "string",
  "status": "READY",
  "stageAttempts": 0,
  "nextAttemptAt": 0,
  "lastError": "string",
  "admittedAt": 0,
  "terminalAt": 0,
  "lastExecutionRecordId": "00000000-0000-0000-0000-000000000000",
  "batchRunId": "00000000-0000-0000-0000-000000000000",
  "batchId": "00000000-0000-0000-0000-000000000000",
  "lastBatchId": "00000000-0000-0000-0000-000000000000",
  "data": null,
  "admittedVia": "API",
  "admittedBy": "string",
  "admittedByExecutionRecordId": "00000000-0000-0000-0000-000000000000",
  "wakeAt": 0,
  "waitingFor": "PERSON",
  "cost": 0,
  "runs": 0
}
Empty
Empty
{
  "type": "string",
  "title": "string",
  "status": 0,
  "detail": "string",
  "instance": "string",
  "property1": null,
  "property2": null
}
{
  "type": "string",
  "title": "string",
  "status": 0,
  "detail": "string",
  "instance": "string",
  "property1": null,
  "property2": null
}

One item's attempt history.

The append-only transition log: what happened to this item and why. The run tree answers a different question: why one attempt behaved as it did.

What happened to the automation's items, bucketed over time.

Per bucket: items admitted, and transitions to DONE (`finished`), IGNORED (`setAside`) and DEAD (`dead`). These are events, not item states: an item re-driven after it finished and finished again counts in both buckets, and an item an operator set aside by hand counts as set aside. Admitted is not part of the other three, because an item usually finishes in a later bucket than it arrived in. Counted from the transition log, which is never purged, so the whole window is counted unless it is longer than 400 days; then only its last 400 days are, and `countedFromMs` says where counting began. Buckets with nothing in them are omitted.