Records what a person found about an effect the platform could not resolve.
The way out of an UNKNOWN effect, which otherwise parks its item permanently. The operator checks the external system and answers the question the platform could not: `LANDED` closes the effect so a later attempt skips the call, `DID_NOT_LAND` reopens it so the next attempt performs it. Answer it wrong in the second direction and the effect is duplicated — which is the failure the durable-effect record exists to prevent — so the reason is required, and only an `UNKNOWN` effect may be settled at all. Returns 409 for any other status: a PENDING row may have a worker mid-call against it. Settling does not re-drive the item; that stays a separate decision.
Authorization
Bearer JWT Authorization header using the Bearer scheme. Enter 'Bearer' [space] and then your token.
In: header
Path Parameters
The automation.
uuidThe ledger item identifier.
uuidThe effect identifier.
uuidThe tenant identifier
What the operator found, and how they know.
What the operator found in the external system. Required.
"UNSPECIFIED" | "LANDED" | "DID_NOT_LAND"How they know — the row they saw, the id they searched. Required.
1 <= length <= 4000The external handle, when settling as landed and the operator has one. Recorded so a hand-settled effect is as auditable as a reconciled one.
length <= 4000Response Body
curl -X POST "https://api.fruxon.com/v1/tenants/string/triggers/497f6eca-6276-4993-bfeb-53cbbbba6f08/ledger/items/497f6eca-6276-4993-bfeb-53cbbbba6f08/effects/497f6eca-6276-4993-bfeb-53cbbbba6f08:settle" \ -H "Content-Type: application/json" \ -d '{ "outcome": "UNSPECIFIED", "reason": "string" }'{
"id": "00000000-0000-0000-0000-000000000000",
"ledgerItemId": "00000000-0000-0000-0000-000000000000",
"effectKey": "string",
"status": "PENDING",
"externalRef": "string",
"detail": "string",
"attempts": 0,
"executionRecordId": "00000000-0000-0000-0000-000000000000",
"createdAt": 0,
"modifiedAt": 0,
"resolvedAt": 0,
"canSettle": false
}{
"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
}{
"type": "string",
"title": "string",
"status": 0,
"detail": "string",
"instance": "string",
"property1": null,
"property2": null
}One item's durable side effects, and how sure the platform is about each.
What this item has done to the outside world. The status that matters is `UNKNOWN`: a previous attempt left the record open, so the platform refuses to repeat the effect and the item cannot pass its stage — re-driving it hits the same refusal. Those rows carry `canSettle`, and `:settle` is how a person who has gone and looked ends the doubt. `docs/design/item-ledger.md §6.4`.
Deliberately excludes a work item, with a reason.
For genuine business exclusions — "group policy, insured is not an agency client" — which must stay visible and distinct from a failure. The reason is required: an exclusion without one is indistinguishable from a bug six months later, and the recorded reason is the only thing separating IGNORED from DEAD.