Activepieces

Provides a canvas-based UI for constructing automation workflows by dragging pieces (actions/triggers) and connecting them with edges. The builder maintains a directed acyclic graph (DAG) representation of the flow, with real-time validation of connections, type checking between piece outputs and inputs, and visual feedback for errors. State is persisted to a backend database and synced bidirectionally with the frontend state management layer.

A plugin architecture where integrations (called 'pieces') are self-contained npm packages exporting action and trigger definitions with authentication, input schemas, and execution logic. The framework uses a registry pattern to load pieces at runtime, with support for both community-maintained and custom pieces. Each piece declares its dependencies, authentication method (OAuth, API key, basic auth), and input/output types via a declarative schema, enabling the builder to validate compatibility and the engine to inject credentials at execution time.

Provides configurable retry mechanisms for pieces that may fail transiently (network errors, rate limits, etc.). Retries can be configured per-piece with exponential backoff, maximum retry count, and retry conditions. The engine logs each retry attempt and can route to error handlers on final failure. Supports both automatic retries and manual retry from the UI for failed runs.

Provides pre-built pieces for interacting with large language models (Claude, GPT, etc.) within workflows. AI pieces support prompt engineering, structured data extraction, and multi-turn conversations. They integrate with the authentication system to manage API keys securely and support multiple LLM providers. Pieces expose parameters for temperature, max tokens, and system prompts, enabling fine-tuning of LLM behavior.

Generates unique webhook URLs for each flow that external services can POST to in order to trigger workflow execution. Webhooks validate incoming payloads against the trigger's schema and extract relevant data into flow variables. Supports custom headers for authentication (e.g., API key validation) and payload transformation before execution. Webhook URLs are persistent and can be shared with external services.

Organizes workflows and credentials into workspaces with role-based access control (RBAC). Users can be assigned roles (admin, editor, viewer) with corresponding permissions for creating, editing, and executing workflows. Workspaces isolate data and credentials, preventing cross-workspace access. Audit logs track user actions for compliance purposes.

Maintains version history for each flow, allowing users to view, compare, and revert to previous versions. Each published version is immutable and can be deployed independently. The engine tracks which version is currently active and can roll back to a previous version if needed. Supports draft and published states, enabling testing before deployment.

Tracks workflow execution counts, API calls, and other usage metrics per workspace. Enforces quotas based on subscription tier, preventing workflows from executing if quotas are exceeded. Provides usage dashboards and billing reports. Supports multiple billing models (per-execution, per-user, etc.).

A distributed execution system where flows are enqueued as jobs (via a message queue, typically Redis or in-memory for self-hosted), picked up by worker processes, and executed step-by-step using a state machine pattern. The engine maintains execution context (variables, step outputs, credentials) throughout the flow, handles branching via router pieces, supports loops with iteration state, and persists run history to the database. Workers are horizontally scalable and can be deployed as separate containers.

Workflows can be initiated via multiple trigger types: webhooks (HTTP POST to a unique endpoint), polling (periodic checks of external services), or manual execution. Webhook triggers generate unique URLs per flow and validate incoming payloads against the trigger's schema. Polling triggers use cron-like scheduling to periodically invoke external APIs and check for new data. The engine deduplicates trigger events to prevent duplicate executions and stores trigger history for audit purposes.

Allows embedding custom code pieces in workflows that execute arbitrary JavaScript/TypeScript in an isolated sandbox environment. The sandbox uses Node.js VM2 or similar isolation to prevent code from accessing the host filesystem or network directly, while providing access to flow variables, step outputs, and a limited set of utilities (JSON parsing, string manipulation). Code pieces can reference previous step outputs via a context object and return structured data to downstream steps.

Router pieces enable conditional branching in workflows based on step outputs or flow variables. Routers evaluate conditions (e.g., 'if step1.status == success') and route execution to different downstream pieces accordingly. The engine supports nested routers for complex decision trees and evaluates conditions at runtime using a simple expression language. Unmatched conditions can route to a default branch or terminate the flow.

Loop pieces enable iterating over arrays or collections within a workflow, executing a sub-flow for each item. The engine maintains iteration state (current item, index, accumulated results) and provides access to loop variables in downstream pieces. Loops support early termination and can aggregate results across iterations. The loop context is isolated from the parent flow context, preventing accidental variable collisions.

Manages credentials for external services using multiple authentication methods: OAuth 2.0 (with automatic token refresh), API keys, basic auth, and custom headers. Credentials are encrypted and stored in the database, with access controlled by workspace permissions. The engine injects credentials into pieces at execution time without exposing them to the flow definition or logs. Supports credential rotation and expiration policies.

Maintains detailed execution history for each workflow run, including step-by-step outputs, error messages, execution duration, and variable state at each step. The UI provides a run details view showing the execution timeline, with the ability to inspect inputs and outputs for each step. Failed runs can be retried from the point of failure. Execution logs are persisted to the database and can be exported for audit purposes.

Enables pausing workflows at any step and resuming them later without losing execution state. When a workflow is paused, the current execution context (variables, step outputs, credentials) is serialized and stored in the database. When resumed, the engine restores the context and continues execution from the paused step. Useful for workflows requiring manual approval or external input.