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:Node Labels
Node Labels
Use the label you assigned to input nodes:
Node IDs
Node IDs
Use the node’s unique ID:
Node ID with Input Name
Node ID with Input Name
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 bystream() 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 acallback_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_urlmust 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, andstoppedstatuses
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 aTextContainer-shaped dict with a has_preview flag and a file reference:
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
Input Validation
Input Validation
Validate inputs before running workflows:
Resource Management
Resource Management
Manage resources efficiently:
Logging and Monitoring
Logging and Monitoring
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