Records the human decision and reopens the parent task for worker resume
On approve, the parent execution is requeued from the parked step and the tool call proceeds with its original arguments; on reject, the rejection text is fed back into the flow as the tool result so the agent can react to (or surface) the operator's reasoning. The responder identity is captured from the caller's auth context, not the request body, so audit trails reflect the real user. Requires Admin role on the agent to prevent arbitrary viewers from authorizing privileged tool calls; to abandon a request without resuming, use `POST .../pendingApprovals/{pendingApproval}:cancel`.
Authorization
Bearer JWT Authorization header using the Bearer scheme. Enter 'Bearer' [space] and then your token.
In: header
Path Parameters
The unique identifier of the agent.
The approval request ID.
uuidThe tenant identifier
The response text.
The approver's reply. Must be non-empty; empty replies are rejected.
Response Body
curl -X POST "https://api.fruxon.com/v1/tenants/string/agents/string/pendingApprovals/497f6eca-6276-4993-bfeb-53cbbbba6f08:respond" \ -H "Content-Type: application/json" \ -d '{}'{
"id": "00000000-0000-0000-0000-000000000000",
"agentId": "string",
"agentRevision": 0,
"flow": "string",
"sessionId": "string",
"taskQueueId": 0,
"executionRecordId": "00000000-0000-0000-0000-000000000000",
"gateType": "TOOL_FLOW_STEP",
"stepIdentifier": "string",
"toolCallId": "string",
"toolKey": "string",
"outboundMessage": "string",
"proposedParameters": {},
"authorizedApprovers": [
"string"
],
"deliveryRoute": {
"id": "00000000-0000-0000-0000-000000000000",
"connectorId": "00000000-0000-0000-0000-000000000000",
"provider": "string",
"integrationConfigId": "00000000-0000-0000-0000-000000000000",
"environmentSlug": "string",
"parameters": {}
},
"deliveryMessageId": "string",
"correlationToken": "string",
"status": "PENDING",
"expiresAt": 0,
"respondedAt": 0,
"respondedBy": "string",
"decision": "APPROVE",
"responseText": "string",
"createdAt": 0,
"modifiedAt": 0
}{
"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
}{
"type": "string",
"title": "string",
"status": 0,
"detail": "string",
"instance": "string",
"property1": null,
"property2": null
}Lists approval requests across the agents of the caller's Applications, newest first
The one approvals list: the deprecated `GET .../agents/{agent}/pendingApprovals` is an alias of this query narrowed by `agentId`. Each item carries its `agentId`, so inbox rows can route their respond/cancel actions to the agent-scoped endpoints (which enforce per-agent Admin access). Naming an Application — or an `agentId` in an Application — the caller cannot open is a 403. The `networkId` filter mirrors the one the escalation queue and access-request list already take, so the Inbox can scope all three of its folders server-side instead of post-filtering a tenant-wide page (which silently under-fills the page it is filtering).
Lists unhandled-escalation events across the tenant, newest first.
Lists recent unhandled escalations. Use sinceMs to change the default lookback window. Each item includes agentId, topicId/participantId and the failure reason. Reading does not retry the escalation.