Code runtime

Stacksona for Custom REST

Call the Gate Agent API directly from any HTTP-capable runtime before executing the governed action.

Where Gate goes

In your service or runtime immediately before the external API call, write, deployment, mutation, or other side effect.

Keep the platform's normal reasoning and orchestration. Gate only the exact action at the last safe point before execution.

Runtime builds request→POST exact action to Gate→Execute, wait, revise, or stop

Start here

1
Build the final action.
Let Custom REST choose the action and produce the arguments it intends to execute.
2
Check the exact action with Gate.
Send tool_name and the final payload immediately before the side effect.
3
Follow one of four outcomes.
Continue, wait, revise, or stop. You do not need the advanced features to get this basic path working.

Minimal setup

bash

curl -sS -X POST "$STACKSONA_GATE_URL/api/agent/tasks/order-1042/requests" \
  -H "Authorization: Bearer $STACKSONA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"tool_name":"issue_refund","payload":{"amount":389.99,"currency":"usd"}}'

Handle the decision

Outcome	Gate status	What Custom REST should do
Continue	`allow` or `approved`	Execute the exact proposed action. If signed proof is required, validate it first.
Wait	`pending_review`	Store `thread_id` and resume that exact review later.
Revise	`changes_requested`	Return reviewer feedback to the part of the runtime that can revise the proposal.
Stop	`reject` or `rejected`	Do not execute. Replan, fall back, or end the action.

Unknown or failed decision = stop.

Fail closed if Gate cannot be reached, returns an unknown state, or required approval proof is missing or invalid.

Platform notes

Only tool_name is required for the decision request; add reviewer context as useful.
Prefer exact thread_id when resuming a human review.
Use webhooks or durable jobs when a review may take longer than one live request.

Advanced: review threads, revisions, proof, and audit

task_id is your grouping ID. thread_id identifies the exact Gate review and should be persisted whenever work can pause.

For changes_requested, revise on the same review thread using the revision event contract. For high-impact actions that require signed proof, validate the returned approval token before execution. Log execution success or failure when you need complete audit evidence.

For long reviews, use the platform's durable continuation mechanism instead of keeping a process, workflow, or runner open.

Advanced runtime patterns Full Gate API Exact decision states