Answers a question on behalf of the person who could not be reached.
The answer travels the same path a channel reply takes, so the two behaviours that make batch answering safe are preserved rather than reimplemented: the reply interpreter fails closed (anything it cannot map with confidence advances nothing), and each item advances only when the ASK stage's `answeredWhenPath` is actually filled in — answering two of three advances two and leaves one WAITING for the deadline. Write it the way you would write it to a colleague. A conforming `{"answers":{"<item key>":"…"}}` payload is also accepted verbatim and skips the model. Returns 400 when nothing in the answer could be matched to an item — the interpreter refuses to guess, so nothing moves and the question stays open and answerable; 409 when a reply, a cancellation or the expiry sweeper settled it first.
Authorization
Bearer JWT Authorization header using the Bearer scheme. Enter 'Bearer' [space] and then your token.
In: header
Path Parameters
The question identifier.
uuidThe tenant identifier
The answer.
The answer, in the operator's own words. Required — an empty answer is not a partial answer, it is a no-op that would spend the question's only settlement.
Free text rather than a per-item map, because that is what the reply path takes:
LedgerAskReplyInterpreter maps prose onto the batch's members and fails closed, so an
answer it cannot place with confidence leaves every item waiting rather than advancing the
wrong one. An already-conforming {"answers":{…}} payload still passes straight through.
1 <= length <= 4000Response Body
curl -X POST "https://api.fruxon.com/v1/tenants/string/batchQuestions/497f6eca-6276-4993-bfeb-53cbbbba6f08:answer" \ -H "Content-Type: application/json" \ -d '{ "answer": "string" }'{
"id": "00000000-0000-0000-0000-000000000000",
"agentId": "string",
"networkId": "00000000-0000-0000-0000-000000000000",
"slotName": "string",
"question": "string",
"delivery": "DELIVERED",
"deliveryDetail": "string",
"expiresAt": 0,
"createdAt": 0,
"batchId": "00000000-0000-0000-0000-000000000000",
"batchStatus": "OPEN",
"stageId": "string",
"waitingCount": 0,
"gatheringUntil": 0,
"lastJoinedAt": 0,
"ledgerId": "00000000-0000-0000-0000-000000000000",
"triggerId": "00000000-0000-0000-0000-000000000000",
"triggerName": "string"
}{
"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
}Lists the questions automations are waiting on a person for.
Soonest deadline first — every row is work that fails if nobody acts, so time left is the useful ordering. Each row carries whether the question actually reached anyone (`delivery`), how many items are parked on it, and its automation, so an undelivered question can be told apart from one somebody is thinking about and opened in the Work view.
Creates a new trigger in an Application and optionally binds it to agents atomically.
Creates the trigger together with any initial agent bindings supplied in the request, in a single transaction. The trigger `Kind` (schedule, webhook, or integration event) is fixed at creation — changing it later requires recreating the trigger, since each kind carries its own configuration shape. The owning Application is the `network` path segment. Every trigger belongs to exactly one, and an unowned trigger would be listed by no Application while still firing, so ownership is part of the address rather than an omittable body field. The created trigger is read and edited on the flat `{tenant}/triggers/{trigger}` tree, which is where the Location header points.