Execution

Scrydon's execution engine brings your workflows to life by processing blocks in the correct order, managing data flow, and handling errors gracefully.

Documentation Overview

Key Concepts

Topological Execution

Blocks execute in dependency order, similar to how a spreadsheet recalculates cells. The execution engine automatically determines which blocks can run based on completed dependencies.

Path Tracking

The engine actively tracks execution paths through your workflow. Router and Condition blocks dynamically update these paths, ensuring only relevant blocks execute.

Layer-Based Processing

Instead of executing blocks one-by-one, the engine identifies layers of blocks that can run in parallel, optimizing performance for complex workflows.

Execution Context

Each workflow maintains a rich context during execution containing:

• Block outputs and states
• Active execution paths
• Loop and parallel iteration tracking
• Environment variables
• Routing decisions

Execution Triggers

Workflows can be executed through multiple channels:

• Manual: Test and debug directly in the editor
• Webhooks: Respond to external events from third-party services
• Scheduled: Run on a recurring schedule using cron expressions
• Deployment: Promote a workflow version to a workspace environment and call the execution endpoint with a workspace API key. Promoted workflows can also be published as A2A agents.

Each trigger passes data to your workflow's starter block, beginning the execution flow.

Programmatic Execution

There are two ways to call a deployed workflow from code, depending on who is making the call:

Server-to-server (API key)

Backends, cron jobs, CI, and internal services authenticate with a workspace API key. There is no SDK — call the workflow API directly:

curl -X POST "https://scrydon.com/api/workflows/{workflowId}/execute" \
  -H "x-api-key: $SCRYDON_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"input": "Hello"}'

Acting on behalf of a user (OAuth)

First-party apps (browser, TanStack Start / Next.js) authenticate the end user with OAuth 2.0 + PKCE through the Client SDK:

npm install @scrydon/sdk

import { ScrydonClient } from '@scrydon/sdk'

const client = new ScrydonClient({
  baseUrl: 'https://scrydon.com',
  clientId: 'your-oauth-client-id',
  redirectUri: 'https://your-app.com/auth/callback',
})

// After client.auth.signIn() / handleCallback() — see Client SDK docs
const result = await client.workflows.trigger({
  workflowId: 'wf_…',
  inputs: { message: 'Hello' },
})
// result: { executionId, status, outputs }

For long-running workflows, use client.workflows.triggerAsync(...) and poll client.workflows.getStatus(executionId).

Best Practices

Design for Reliability

• Handle errors gracefully with appropriate fallback paths
• Use environment variables for sensitive data
• Add logging to Function blocks for debugging

Optimize Performance

• Minimize external API calls where possible
• Use parallel execution for independent operations
• Cache results with Memory blocks when appropriate

Monitor Executions

Monitor refreshes visible dashboard data every 5 seconds by default. Use the refresh-rate selector to choose 5, 15, or 30 seconds, 1 minute, or Off. Automatic polling pauses while the browser tab is hidden. Refresh reloads the currently visible Monitor data immediately, including when automatic refresh is off. This cadence controls browser dashboard queries only; it does not change how often an integration provider is polled for new events.

• Review logs regularly to understand performance patterns
• Track costs for AI model usage
• Use workflow snapshots to debug issues

What's Next?

Start with Execution Basics to understand how workflows run, then explore Logging and Cost Calculation to monitor and optimize your executions.