Skip to main content

Overview

Once you’ve built and saved a workflow, you can execute it with different inputs and monitor its progress. The Noxus SDK provides both synchronous and asynchronous methods for running workflows and handling results.

Basic Workflow Execution

Running a Workflow

Input Formats

The input format depends on how you configured your workflow nodes:
Use the label you assigned to input nodes:
Use the node’s unique ID:
Use the format {node_id}::{input_name}:

Monitoring Execution

Synchronous Monitoring

Wait for workflow completion with custom intervals:

Asynchronous Monitoring

For non-blocking execution monitoring:

Manual Status Checking

For more control over monitoring:

Real-Time Streaming

Instead of polling for run completion, you can stream events in real time using Server-Sent Events (SSE). This gives you instant notifications as nodes execute and when the run finishes.

Streaming Run Events

One-Liner: Run and Stream

Create a run and immediately stream its events in a single call:

Async Streaming

RunEvent Properties

Each event yielded by stream() is a RunEvent object:
run.wait() now uses SSE streaming internally for instant completion detection. If the SSE endpoint is unavailable, it automatically falls back to polling.

Webhook Callbacks

For event-driven integrations, you can provide a callback_url when creating a run. The platform will POST the run result to your URL when the run reaches a terminal state (completed, failed, or stopped).

Setting Up a Callback

Webhook Payload

Your endpoint receives a POST with this JSON body:

Webhook Behavior

  • Retries: Failed deliveries are retried up to 3 times with exponential backoff (1s, 5s, 15s)
  • Validation: The callback_url must be a valid HTTP(S) URL — invalid URLs are rejected at creation time
  • Non-blocking: Webhook delivery never affects run execution — if your endpoint is down, the run still completes normally
  • Terminal states: Webhooks fire on completed, failed, and stopped statuses

Handling Different Input Types

Text Inputs

File Inputs

Multiple Inputs

Fixed vs Dynamic Inputs

Result Handling

Understanding Run Results

Processing Output Data

Large or Truncated Text Outputs

When a text output exceeds 16,000 characters, the API does not return the full string inline. Instead, it truncates the value in the response, uploads the full content to file storage, and returns a TextContainer-shaped dict with a has_preview flag and a file reference:
Detect this shape via has_preview and fetch the full content through the Files API:
has_preview only appears on outputs that were actually truncated. Outputs that fit under the 16,000-character limit are returned either as a plain string or as {"text": "..."} without a file reference, so always guard on has_preview before attempting to download.

Saving Results

Batch Processing

Running Multiple Workflows

Processing Multiple Inputs

Error Handling

Handling Execution Errors

Retry Logic

Performance Optimization

Efficient Polling

Concurrent Execution with Limits

Best Practices

Validate inputs before running workflows:
Manage resources efficiently:
Implement comprehensive logging:

Next Steps

Node Types

Learn about all available node types and their capabilities

Workflow Examples

Explore complete workflow examples for common use cases

Advanced Patterns

Master advanced workflow design and execution patterns

API Reference

Detailed API reference for workflow execution