Platform guide

Stacksona for Dify

Use HTTP request and human input style workflow nodes to call Stacksona before the workflow runs sensitive tools or app actions.

Call Stacksona from workflow HTTP nodes before Dify executes sensitive tool or app actions. This page shows the recommended integration pattern using HTTP, a wrapper, or a small bridge service.

Start with this decision step

Every recipe should create a Stacksona decision before the platform executes the risky action.

pseudo
1. Agent prepares a risky action.
2. Platform calls Stacksona with action details.
3. If decision is allow or approved, execute the action.
4. If decision is pending_review, wait, poll, or resume through callback.
5. If decision is reject or rejected, do not execute.

Recommended pattern

StepDescription
HTTP requestCall the Stacksona Gate request endpoint with workflow, task, tool, subject, risk, and payload.
BranchRoute allow to the action, reject to stop, and pending_review to a waiting or callback path.
CallbackUse a webhook callback or scheduled check to continue after the reviewer decides.

Example

bash
curl -X POST "$STACKSONA_GATE_URL/api/agent/tasks/task-refund-8821/requests"   -H "Authorization: Bearer $STACKSONA_API_KEY"   -H "Content-Type: application/json"   -d '{
    "workflow_name": "Customer Support",
    "task_label": "Refund request for order #8821",
    "tool_name": "issue_refund",
    "subject": "Issue a $500 refund to customer cus_99",
    "risk_level": "high",
    "payload": { "amount": 500, "currency": "usd", "customer_id": "cus_99" }
  }'

Decision handling

StatusWorkflow behavior
allowContinue immediately.
rejectStop the action before execution.
pending_reviewPause, poll, or wait for callback. Continue only after approved.
approvedExecute the action. Validate token first when signed approval is required.
rejectedDo not execute. Route to fallback, manual task, or safe response.

Integration FAQ

Can I use Stacksona with Dify today?

Yes. Use the documented native package when one exists. Otherwise, use the REST API, HTTP module, webhook action, or a small Node sidecar with @stacksona/sdk.

Where should Stacksona sit in a Dify workflow?

Place Stacksona immediately before the action that sends, updates, deletes, refunds, posts, deploys, or calls a production API.

What statuses should my workflow allow?

Execute the gated action only on allow or approved. Stop, retry, notify, or route to fallback for every other state.