Skip to main content
Scout workflows run from multiple surfaces: the Studio Console for development and debugging, the REST API and SDKs for production systems, and webhook triggers for event-driven integrations. Each approach targets a different stage of your workflow’s lifecycle — test locally first, then move to the API or SDK when you’re ready to integrate with external systems.

​
Running from the Console

The Console is the fastest way to test a workflow during development. Open it by clicking the play icon on the workflow canvas in Studio. Type or paste an input payload, click Run, and watch each block’s output appear in real time as the workflow executes. You can inspect the input and output of every individual block without writing a single line of integration code. Use the Console to:
  • Confirm your input payload shape before wiring up a real trigger or API call
  • Spot errors in individual blocks without deploying anything
  • Test edge cases quickly — paste a bad payload to confirm your validation logic fires correctly
  • Reproduce a production failure by copying the input from a failed run in Logs
Always test with real data, not placeholder strings like "test". Edge cases and formatting issues surface immediately with actual values.

​
Running via REST API

Trigger a workflow from any backend service, script, or automation tool using the Scout REST API. Send a POST request to the workflow execute endpoint, passing your inputs in the request body. 
curl -X POST "https://api.scoutos.com/v2/workflows/{workflow_id}/execute?environment=production" \
  -H "Authorization: Bearer $SCOUT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "inputs": {
      "ticket_id": "TKT-4821",
      "subject": "Cannot access billing portal",
      "body": "I have been trying to log in to the billing portal for two days and keep getting a 403 error.",
      "customer_email": "jane.doe@example.com"
    },
    "streaming": false
  }'
A successful response includes the run ID, status, duration, and your workflow’s output fields: 
{
  "run_id": "run_abc123xyz",
  "status": "success",
  "outputs": {
    "ticket_id": "TKT-4821",
    "urgency": "high",
    "routed_to": "billing-support",
    "status": "processed"
  },
  "duration_ms": 1840
}
Replace {workflow_id} with your workflow’s ID, found in the workflow settings panel in Studio. Set environment to development, staging, or production depending on which revision you want to run.

​
Running via SDK

The Python and TypeScript SDKs wrap the REST API with type safety, automatic retries, and streaming support. Use the SDK when integrating Scout into your application backend. 
from scoutos import Scout

client = Scout(api_key="YOUR_API_KEY")

result = client.workflows.execute(
    workflow_id="wf_support_triage",
    inputs={
        "ticket_id": "TKT-4821",
        "subject": "Cannot access billing portal",
        "body": "I have been trying to log in to the billing portal for two days and keep getting a 403 error.",
        "customer_email": "jane.doe@example.com",
    },
    environment="production",
)

print(result.outputs["urgency"])     # "high"
print(result.outputs["routed_to"])   # "billing-support"

​
Streaming

For workflows that include LLM blocks or other long-running steps, use streaming to receive output tokens as they arrive rather than waiting for the full response. This is especially useful when surfacing LLM-generated text directly in a UI. 
stream = client.workflows.execute_stream(
    workflow_id="wf_support_triage",
    inputs={
        "ticket_id": "TKT-4821",
        "subject": "Cannot access billing portal",
        "body": "I have been trying to log in for two days and keep getting a 403 error.",
        "customer_email": "jane.doe@example.com",
    },
    environment="production",
)

for chunk in stream:
    print(chunk.delta, end="", flush=True)

​
Webhook Triggers

Configure a webhook trigger on your workflow to run it automatically whenever an external service sends an HTTP event — a form submission, a payment notification, a CRM update, or any other webhook-capable tool. When you add a webhook trigger in Studio, Scout generates a unique endpoint URL: 
https://hooks.scoutos.com/v1/workflows/{workflow_id}/webhook/{token}
Paste this URL into your external service’s webhook configuration. When the service sends a POST request to this URL, Scout runs the workflow immediately, passing the entire request body as {{ inputs.webhook_body }}.
Webhook triggers always run against the production revision of your workflow. Test your webhook handling in the Console first by pasting a sample payload from your external service.

​
Targeting Environments

Always specify an environment when calling via the API or SDK. This determines which revision of your workflow runs — not just a label.
EnvironmentWhen to use
developmentActive building and iterating in Studio
stagingPre-production validation with realistic inputs
productionLive user traffic and production integrations
Targeting staging explicitly lets you run automated checks against a pre-production revision before promoting it: 
curl -X POST "https://api.scoutos.com/v2/workflows/{workflow_id}/execute?environment=staging" \
  -H "Authorization: Bearer $SCOUT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"inputs": {"ticket_id": "TKT-9999", "subject": "smoke test", "body": "This is a staging smoke test.", "customer_email": "test@example.com"}}'
See Environments for how to promote revisions across stages and roll back safely.

​
Next Steps

Environments

Promote workflow revisions from development to production and roll back when needed.

Logs

Inspect run status, duration, and block-level output after each execution.

Blocks

Understand what each block type does and how to connect them.

Creating Workflows

Structure your workflow with the validate-fetch-decide-act-return pattern.