Inputs, execution, and triggers

Supply inputs

Workflow inputs are described with JSON Schema. Source workflows derive their parameters from the function signature. In Studio, select Start → Types to inspect or edit the supported parameter contract, then use the invocation form or JSON input when running the workflow.

For individual nodes, use the Inspector's I/O controls to set fixed values. Expressions such as {{ $json.field }} can read values from the node's input. Keep inputs JSON-compatible and satisfy the required fields shown by the schema.

From the CLI:

octonode run total --config .octonode.yaml --input '{"a":2,"b":3}' --json

--json prints the full run record. Without it, the CLI prints terminal outputs.

Call a workflow over HTTP

Copy the complete POST URL from Start → Endpoint. It uses /wf/exec?id=…; /api/wf/exec is the equivalent documented API route. Preserve any project and workspace parameters in the copied URL. The workflow identifier is not a credential.

Set WORKFLOW_URL to that copied URL and WORKFLOW_API_TOKEN to an authorized token with workflows:run access for the target workspace and project, then call:

curl --fail-with-body "$WORKFLOW_URL" \
  -H "Authorization: Bearer $WORKFLOW_API_TOKEN" \
  -H 'Content-Type: application/json' \
  --data '{"a":2,"b":3}'

Send the target workflow's input object directly as the request body. The response includes runId, workflowId, status, outputs, and durationMs.

Check the JSON status, even after HTTP 200. An admitted run can finish with error or partial. Authentication failures, invalid requests, missing workflows, and full queues use HTTP errors. Stopping the HTTP client from waiting does not cancel an already admitted execution.

The Endpoint call builder can generate examples for Node.js, Go, Python, cURL, and Java. Copying an example does not execute the workflow. For the complete API contract on your deployment, open API docs in the Playbook navigation.

Add triggers

Start → Triggers manages webhook and scheduled subscriptions. Save workflow changes separately from trigger changes: saving a subscription does not save unsaved canvas topology. Configure the subscription for the intended environment and input before enabling it.

Native scheduling is available on supported cloud deployments and accepts a five-field cron expression in the selected IANA timezone. Enable both the subscription and Activate workflow triggers, then choose Save triggers. The panel shows the registered next occurrence and admission errors.

Webhook subscriptions accept a JSON event body at the subscription's authenticated event endpoint. Use a stable Idempotency-Key for each event so repeated deliveries reuse the same execution admission. External schedule subscriptions use that event endpoint with an eventId and payload; their saved input supplies the workflow parameters. Saving an external schedule does not create a native scheduled job.

A trigger delivery response with HTTP 202 means the run is queued. Follow the run's status in execution history. Alternatively, an external scheduler can call the direct execution URL documented above.

The scheduling active switch controls scheduled execution. Explicit authorized HTTP calls can still execute a workflow independently of that switch.

Handle failures

Node runtime settings support timeouts, retries, and retry backoff. Configure retries only when repeating the operation is acceptable or the operation is idempotent. See runtime configuration for the fields and Troubleshooting for diagnosing failed runs.