Execution and Webhooks
The Workflow Builder V2 execution engine provides reliable, scalable workflow execution with durability guarantees. This guide covers the execution lifecycle, integration patterns, and operational considerations for running workflows in production.
Execution Lifecycle
Every workflow execution progresses through a defined set of states.
Execution States
| State | Description |
|---|---|
PENDING | Execution created, waiting to start |
RUNNING | Workflow actively executing tasks |
COMPLETED | Workflow finished successfully |
FAILED | Execution failed with an error |
CANCELLED | Execution was manually cancelled |
State Transitions
PENDING to RUNNING
The execution transitions to RUNNING when:
- The system schedules the workflow
- A processing slot becomes available
- The start task begins processing
RUNNING to COMPLETED
The execution completes successfully when:
- All tasks in the execution path finish without errors
- The end task produces the final output
- No unhandled exceptions occur
RUNNING to FAILED
The execution fails when:
- A task throws an unhandled exception
- Retry attempts are exhausted
- A timeout is exceeded
- An exception task is triggered
RUNNING to CANCELLED
The execution is cancelled when:
- A user manually cancels via the UI or API
- A parent workflow cancels a child workflow
- System-level cancellation is triggered
Monitoring Execution State
You can monitor execution state through:
- UI Dashboard: Real-time status updates with visual indicators
- API Polling: Query
/v1/executions/{id}for current status - Webhooks: Configure callbacks for state transitions
Polling Pattern with Retry Logic
For asynchronous executions, implement polling with exponential backoff:
Webhook Integration
Configure webhooks to receive real-time notifications when executions complete, eliminating the need for polling.
The quickest way to set them up is from the AltScore hub, under Settings > Webhooks: there you register your
endpoint, subscribe it to the bc.execution.completed event, get the signing secret and browse the delivery history.
The Webhooks guide covers signature verification and retries in detail.
Webhook Payload Structure
When an execution completes, AltScore sends a POST request to your configured endpoint. The execution data travels in
data.entity:
data.entity is the execution object. The event envelope and the rest of the available events are described in
Events.
Webhook Handler Example
Every delivery is signed with the svix-id, svix-timestamp and svix-signature headers. Verify the signature against
the raw body before processing anything: without it, anyone who knows the URL can send you a forged execution. You get
each endpoint's secret from Settings > Webhooks.
Pass verify the raw body, unparsed and unserialized: the signature is computed over the exact bytes you received. And
make your handler idempotent, keyed on svix-id: a retry can duplicate an event you already processed.
Registering a Webhook
Besides the hub, you can register it via API:
The full reference is in Webhooks API.
Webhooks are the recommended approach for production integrations. They eliminate polling overhead and provide real-time notifications. Use polling only for simple integrations or when webhooks are not feasible. If a delivery fails, Svix retries it automatically and you can retry it by hand from Settings > Webhooks.
Synchronous vs Asynchronous Execution
Workflow Builder supports both synchronous and asynchronous execution modes to accommodate different use cases.
Synchronous Execution
In synchronous mode, the API request waits for the workflow to complete before returning.
Request
Response (returned after workflow completes)
When to use synchronous execution:
- Real-time decisions needed in user-facing flows
- Workflows that complete in under 30 seconds
- Integration with systems expecting immediate responses
Synchronous execution has a default timeout of 30 seconds. For workflows that may take longer, use asynchronous execution with polling.
Asynchronous Execution
In asynchronous mode, the API returns immediately with an execution ID. Poll for results or configure webhooks.
Request
Response (returned immediately)
Polling for results
When to use asynchronous execution:
- Workflows involving slow external APIs
- Batch processing scenarios
- Background processing where immediate response is not needed
- Workflows with wait tasks
Batch Execution
Batch execution allows processing multiple items through the same workflow, with built-in orchestration for pre-processing, execution, and post-processing.
Batch Lifecycle
Batch States
| State | Description |
|---|---|
pending | Batch created, waiting to start |
pre_processing | Validating and preparing input data |
processing | Executing workflows for each item |
post_processing | Generating output files and reports |
complete | Batch finished |
failed | Batch failed during any phase |
Creating a Batch
Response
Batch Configuration Options
| Option | Type | Description |
|---|---|---|
| parallelism | number | Max concurrent workflow executions (default: 10) |
| stopOnError | boolean | Stop batch on first error (default: false) |
| notifyOnComplete | boolean | Send webhook when batch completes |
| outputFormat | string | Format for output files: "json", "csv" |
Pre-Processing Phase
During pre-processing, the system:
- Validates input data: Ensures all items have required fields
- Parses input files: Handles CSV, JSON, or other file formats
- Transforms data: Applies any configured transformations
- Creates execution records: Prepares individual executions for each item
If pre-processing fails (e.g., invalid data format), the batch moves to failed state without executing any workflows.
Processing Phase
During processing:
- Items are processed according to parallelism settings
- Each item triggers a separate workflow execution
- Individual failures don't stop other items (unless
stopOnErroris true) - Progress is tracked and available via API
Monitoring batch progress
Post-Processing Phase
After all items are processed:
- Generate output files: Compile results into downloadable files
- Create summary reports: Aggregate statistics and outcomes
- Trigger webhooks: Notify external systems of completion
- Clean up resources: Archive temporary data
Retry Policies
The execution engine supports configurable retry policies at both the workflow and task level.
Default Retry Behavior
| Configuration | Default Value |
|---|---|
| Max attempts | 3 |
| Initial interval | 1 second |
| Backoff coefficient | 2.0 |
| Max interval | 60 seconds |
Task-Specific Retry Policies
Different task types have tailored retry behaviors:
HTTP Tasks
Python Tasks
External Integration Tasks
Configuring Custom Retry Policies
In the Advanced tab of task configuration:
| Setting | Description |
|---|---|
| Max Retries | Maximum number of retry attempts |
| Initial Delay | Time before first retry (seconds) |
| Max Delay | Maximum time between retries (seconds) |
| Backoff Multiplier | Factor to increase delay between retries |
Be cautious with retry policies for tasks that modify external state. Ensure operations are idempotent or use appropriate safeguards to prevent duplicate processing.
Retry vs. Workflow Restart
Understanding when retries occur vs. when a full restart is needed:
| Scenario | Behavior |
|---|---|
| Transient network error | Automatic retry at task level |
| Task timeout | Retry up to max attempts |
| Invalid input data | Fail without retry |
| External service down | Retry with exponential backoff |
| Code exception in Python | Fail without retry |
| Workflow timeout | Requires manual restart |
Error Handling
The execution engine provides comprehensive error handling capabilities.
Error Capture
When a task fails, the engine captures:
- Error message: Human-readable description
- Error code: Machine-readable identifier
- Stack trace: Full execution trace (for debugging)
- Task context: Input data and configuration at time of failure
- Execution history: All events leading to the failure
Error Categories
| Category | Description | Typical Response |
|---|---|---|
| Validation | Input data doesn't meet requirements | Fail fast, provide clear message |
| External | Third-party service unavailable | Retry with backoff |
| Timeout | Operation exceeded time limit | Retry or fail based on config |
| Authorization | Permission denied | Fail, log security event |
| Business Logic | Policy or rule violation | Fail, capture decision context |
| Infrastructure | System-level failure | Automatic recovery |
Exception Handling in Workflows
Use the exception task to implement explicit error handling:
Viewing Error Details in UI
Failed tasks display error information:
- Node indicator: Red border and error icon on failed tasks
- Properties panel: Full error details in the Logs tab
- Execution history: Timeline view showing where failure occurred
- Error context: Input values and configuration at failure point
Programmatic Error Handling
When calling the execution API:
Error Recovery Strategies
| Strategy | Description | When to Use |
|---|---|---|
| Automatic retry | Engine retries failed tasks | Transient failures |
| Manual retry | User triggers retry via UI/API | After fixing root cause |
| Skip and continue | Mark task as skipped, continue workflow | Non-critical tasks |
| Compensating action | Execute cleanup/rollback logic | Partial failures |
| Escalation | Create alert for human review | Complex failures |
Implementing Error Recovery in Code
Performance Considerations
Execution Throughput
- The system can process hundreds of concurrent workflow executions
- Task parallelism within a workflow is limited by dependencies
- Batch processing scales horizontally to handle increased load
Latency Optimization
- Minimize external calls: Batch data retrieval where possible
- Use caching: Leverage data source caching for repeated lookups
- Optimize task order: Place fast-failing validations early
- Configure appropriate timeouts: Avoid waiting for unresponsive services
Monitoring and Alerting
Track these metrics for healthy execution:
| Metric | Description | Alert Threshold |
|---|---|---|
| Execution duration | Time from start to completion | > 2x average |
| Task failure rate | Percentage of failed tasks | > 5% |
| Queue depth | Pending executions waiting | > 100 |
| System utilization | Processing capacity usage | > 80% |
Best Practices
Designing for Reliability
- Make tasks idempotent: Safe to retry without side effects
- Handle partial failures: Use compensating transactions when needed
- Set appropriate timeouts: Balance between reliability and responsiveness
- Log key decisions: Include context for debugging and auditing
Production Deployment
- Use async execution: Avoid blocking on long-running workflows
- Monitor execution queues: Alert on growing backlogs
- Configure webhooks: Integrate with monitoring systems
- Plan for failure: Implement alerting and escalation procedures
Testing Workflows
- Use test mode: Execute with sample data before publishing
- Verify error handling: Test failure scenarios explicitly
- Monitor execution logs: Review task-level output during testing
- Test at scale: Validate batch processing with realistic volumes