Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.kadoa.com/llms.txt

Use this file to discover all available pages before exploring further.

​
Understanding Workflow Status

When you view a workflow in the dashboard or API, you’ll see a status that tells you what’s happening. This status is computed from two underlying values.

​
What You See (displayState)

The status shown in the dashboard:
StatusMeaningdisplayState
SetupYou’re still configuring this workflow. Finish setup to start the first run.DRAFT
BuildingKadoa is generating the scraper code for this workflow. You’ll be notified when it’s ready.SETUP
Sample ProcessingKadoa is generating sample data so you can review what the workflow will extract.QUEUED / PENDING_START
Needs ReviewSample data is ready. Review and approve it to get the full dataset.PREVIEW
In Human ReviewRun finished extraction and is being reviewed by our team before the data is delivered. Reviews usually take a few hours.VALIDATING
RunningA job is currently extracting data, or a real-time monitor is collecting data normally.RUNNING
ScheduledLast run finished successfully, future runs are scheduled.ACTIVE
CompleteLast run finished successfully, no future runs scheduled.ACTIVE
PausedWorkflow is paused.PAUSED
FailedLast run encountered an error.FAILED
Degraded(Real-time monitors only) No data received for more than 15 minutes.DEGRADED

​
Real-time monitor health

Real-time monitors run continuously and are health-checked automatically. If a monitor stops receiving data, its status changes: Running → Degraded (after 15 min) → Failed (after 30 min)
  • Degraded — Our team has been notified and is investigating.
  • Failed — A support case has been opened and you’ll be notified when it’s resolved.
Monitors recover to Running automatically once the issue is resolved. This is different from scheduled workflows, where a failed status stays until the next run succeeds.

​
API Response Fields

The API returns three state-related fields: 
{
  "state": "ACTIVE",
  "runState": "FINISHED",
  "displayState": "ACTIVE"
}
FieldPurposeWhen to Use
displayStateWhat users see in the dashboardUse this for filtering and display
stateWorkflow lifecycle (enabled/paused/deleted)Admin operations
runStateLatest job result (running/finished/failed)Job-level debugging
For workflows still in setup, both state and displayState are DRAFT until the workflow leaves the setup lifecycle.

​
Filtering Workflows

When filtering workflows via the API, use the displayState parameter: 
# Get all completed/scheduled workflows (both show as displayState=ACTIVE)
GET /v4/workflows?displayState=ACTIVE

# Get workflows still in setup
GET /v4/workflows?displayState=DRAFT

# Get workflows being reviewed by our team before delivery ("In Human Review")
GET /v4/workflows?displayState=VALIDATING

# Get failed workflows
GET /v4/workflows?displayState=FAILED

# Get paused workflows
GET /v4/workflows?displayState=PAUSED

# Get workflows pending review
GET /v4/workflows?displayState=PREVIEW

# Get degraded monitors
GET /v4/workflows?displayState=DEGRADED
displayState is computed by combining state and runState. For example, a workflow with state=ACTIVE and runState=FAILED will have displayState=FAILED. Some lifecycle states map directly, such as DRAFT, PAUSED, and PREVIEW. For real-time monitors, displayState can also be DEGRADED or FAILED based on monitor health.