Update an existing workflow’s configuration, nodes, or settings
text or jsonACTIVE or INACTIVEWorkflowResponse object.
deploy=true to immediately apply changesdeploy=true, changes are staged and require a separate Deploy Workflow callAPI Key for authentication
Automatically deploy the workflow after updating to apply changes immediately. Without this, changes are staged but not active until a PUT deploy call.
Request model for updating an existing workflow.
All fields are optional — only provide the fields you want to change. At least one field must be provided. The workflow type remains 'orchestration' and cannot be changed.
Workflow name.
Workflow description.
Emoji icon.
Avatar identifier.
Workflow status: 'ACTIVE' or 'INACTIVE'.
DRAFT, ACTIVE, INACTIVE Default LLM provider.
openai, nim, amazon_bedrock, azure_ai_foundary, huggingFace, friendlyAI, anthropic, gemini, fireworks, google_ai_studio, helicone, bytedance, tzafon_lightcone, open_router, nebius, cloudflare_ai_gw Default model name.
Reasoning depth.
low, medium, high, xhigh Custom LLM API base URL.
LLM credentials key.
Credential type.
xpander, custom Direct LLM credentials.
Extra LLM headers.
Workflow instructions.
Expected output description.
Output format.
text, markdown, json, voice JSON Schema for output.
Updated workflow DAG nodes.
Execution strategies.
Notification settings.
Trigger source nodes.
Deployment type.
serverless, container Access scope.
personal, organizational Target environment.
NeMo guardrails.
Prompt caching.
Event streaming.
OIDC pre-auth.
OIDC audiences.
Forward OIDC to LLM.
OIDC LLM audience.
OIDC MCP audience.
Successful Response
Response model for workflow endpoints.
Inherits from AIAgent but excludes agent-specific fields that are not relevant to workflows (orchestrations). This provides a clean API surface for workflow consumers without exposing confusing agent-only concepts.
The workflow's execution logic is defined in orchestration_nodes — a DAG
of typed nodes. Agent-specific fields like graph, attached_tools,
delegation_*, framework, and agno_settings are hidden.
Enumeration of the agent delegation end strategies.
Attributes: ReturnToStart: when last agent is finished and about to announce "finish" it will summarize and return to the first agent. FinishWithLast: finish at the last agent.
return-to-start, finish-with-last serverless, container personal, organizational Enumeration of possible agent statuses.
Attributes: DRAFT: Agent is in a draft state. ACTIVE: Agent is active and operational. INACTIVE: Agent is inactive and not operational.
DRAFT, ACTIVE, INACTIVE Enumeration of the agent types.
Attributes: Manager: marks the agent as a Managing agent. Regular: marks the agent as a regular agent. A2A: marks the agent as an external agent used via A2A protocol. Curl: marks the agent as an external agent used via a CURL. Orchestration: marks the agent as an Orchestration object.
manager, regular, a2a, curl, orchestration Enumeration of the agent delegation types.
Attributes: Router: Marks the agent as a router agent - xpanderAI's LLM will decide which sub-agent to trigger. Sequence: Marks the agent as a sequence agent - sub-agents will delegate to other sub-agents.
router, sequence Enumeration of the agent delegation memory strategies.
Attributes: Full: The memory object will be passed completely between agents. Summarization: Between each sub-agent delegation, a summarization will occur, and a new thread will be created for each agent. OriginalInput: the sub agent will get the initial task with a fresh memory thread
full, summarization, original-input openai, nim, amazon_bedrock, azure_ai_foundary, huggingFace, friendlyAI, anthropic, gemini, fireworks, google_ai_studio, helicone, bytedance, tzafon_lightcone, open_router, nebius, cloudflare_ai_gw low, medium, high, xhigh text, markdown, json, voice xpander, custom Configuration for event-based notifications.
Attributes: on_success: Notifications to send when an operation succeeds. Maps notification types to a list of notification configurations. on_error: Notifications to send when an operation fails. Maps notification types to a list of notification configurations.
Configuration object for task-level execution strategies.
This model groups optional strategy configurations that control how a task is executed and managed over time, including retries, iterative execution, stopping conditions, and daily run limits.
Attributes: retry_strategy: Optional retry policy configuration that defines how the task should behave when execution fails (e.g., max attempts, backoff rules).
iterative_strategy:
Optional iterative execution configuration for tasks that may run in
repeated cycles/steps until completion or a stop condition is met.
stop_strategy:
Optional stopping policy configuration that defines when the task
should stop running (e.g., timeout, max iterations, success criteria).
max_runs_per_day:
Optional limit on how many times the task is allowed to run within a
24-hour period. If not set, no explicit daily limit is enforced.
agentic_context_enabled:
if agentic memory is enabled and accesible to the executor.