Human approvals

This node is preview. It waits on an active worker and polls for a decision; it does not durably suspend and resume a flow across worker restarts. The execution runtime's timeout can end a run before the approval window. For long reviews, split the workflow into preparation and execution flows, store the review state in your application, and trigger the execution flow after approval.

Configure the node

In the Flow Builder, place Human Approval before the action that needs review. Connect data_in and define separate continuations for approved_out, rejected_out, and timeout_out.

{
  "approval_message":"Approve export for {{customer_id}}?",
  "timeout_hours":0.1,
  "poll_interval_seconds":5,
  "notification_channel":"none",
  "approver_hint":"Data operations"
}

approval_message is required and supports template placeholders from the input data. timeout_hours defaults to 24; the displayed configuration range is 0.1–720 hours. Choose a short window that fits the selected node/run timeout and runtime. poll_interval_seconds defaults to 5.

approver_hint is descriptive; it does not restrict who may decide. The currently exposed notification_channel and webhook_url fields do not dispatch reviewer notifications. Arrange a notification from your own application using the approvals API.

Discover pending reviews

Start the flow, then list pending approvals with an authenticated token carrying runs.read:

curl --fail-with-body "$DAGY_API_URL/approvals?status=pending&limit=100" \
  -H "Authorization: Bearer $DAGY_TOKEN"

The response has approvals and count. Each record identifies the approval_id, run_id, task, flow, review content, status, and decision metadata. Match the record to the intended run before showing it to a reviewer. Read one record with GET /approvals/{approval_id}.

List limits default to 100 and permit 1–500. Do not assume the list is an unlimited history or that a stored pending record means its worker is still waiting; inspect run status too.

Approve or reject

Decisions require runs.trigger:

curl --fail-with-body \
  "$DAGY_API_URL/approvals/$APPROVAL_ID/approve" \
  -H "Authorization: Bearer $DAGY_TOKEN" \
  -H 'Content-Type: application/json' \
  --data '{"comment":"Validated the customer and export destination."}'

Use /reject for rejection. The body is optional; comment records the reviewer's explanation. The response is the current approval record with decision information such as status, decided_by, decided_at, and decision_comment.

The waiting node checks the decision on its next poll. Approval forwards data to approved_out; rejection uses rejected_out; the wait expiring uses timeout_out. Connect every relevant outcome to deliberate handling so rejected or unreviewed data cannot accidentally reach the protected action.

Later sequential decisions on an already decided record return its existing state. Do not assume this is a multi-reviewer voting system or an atomic conflict-resolution guarantee for simultaneous decisions. Your review application should prevent conflicting actions and display the state returned by the server.

Limitations and recovery

There is no public endpoint to create an approval independently of a running node. There is also no durable restart/resume operation for this gate. Stored expiry metadata does not itself expire a record or terminate its worker; the node's wait and execution timeouts determine runtime behavior.

For business-critical approvals, test rejection, expiry, worker timeout, and duplicate decision paths before using the preview node in production.