Configure an Action Node

6.0 manageOrchestrator/writeWorkflows One

Action nodes perform operations that interact with TheHive or external systems in TheHive Flow. They represent the workflow's output, creating changes in the environment or triggering downstream processes.

Configure an HTTP request action node

An HTTP request action node sends HTTP requests to any API accessible from TheHive instance:

• ITSM tools
• Threat intelligence platforms
• Cloud services
• Another TheHive Flow workflow with its Webhook trigger
• TheHive API, for endpoints not covered by the TheHive integration node

Working with TheHive

To create, update, or query objects in TheHive, use the TheHive integration node, which exposes TheHive operations directly. Use an HTTP request node for TheHive API endpoints that the TheHive node doesn't cover, or for any other external API.

1. Go to the Flow view from the sidebar menu.

   

2. Select a workflow from the list.

3. Drag the previous node connector to an empty area of the canvas.

   

4. In the What is the next step? drawer, select Actions.

5. Select HTTP request.

6. In the HTTP request drawer, enter the following information:

   Variables

   Insert a variable with the $var button, or type $ and select a variable from the suggestions. To access a field, select the variable to edit its jq expression, or use the + button to insert the variable and the field together.

   Fields marked with * are mandatory.

   - Method *

   The HTTP method used for the request.

   - URL *

   The full endpoint URL.

   Examples:

   • https://<thehive_host>/api/v1/user
   • https://api.abuseipdb.com/api/v2/check?ipAddress=<ip_address>

   - Headers

   Select in the Headers section to add headers.

   Enter a header key and its corresponding value to include in the HTTP request. Use headers to define content types, expected response formats, or to include custom metadata required by the external system.
   

   - Body

   Variables

   Insert a variable with the $var button, or type $ and select a variable from the suggestions. To access a field, select the variable to edit its jq expression, or use the + button to insert the variable and the field together.

   The request body. Available for POST, PUT, PATCH, and DELETE methods.

   - Multipart parts

   Key-value pairs sent as a multipart/form-data request, one part per pair. Leave Body empty when using this field. A value that is a file reference is streamed as a file part, and any other value is sent as a plain form field. Available for POST, PUT, PATCH, and DELETE methods.

7. Optional: Select Add options to configure the following settings.

   - Authentication

   Configure how the node authenticates when calling the API.

   Calling TheHive API

   If the HTTP request targets TheHive itself, ensure that your TheHive authentication settings are compatible with the method you select in this node.

   Supported methods:

   • None: No authentication is added to the request.

   • Basic auth: Sends a username and password encoded in the Authorization header using the HTTP Basic scheme.

   Field	Example
   Username *	emma@example.com
   Password *	$secret.api_password

   • Bearer token: Sends an access token in the Authorization header using the Bearer scheme.

   Field	Example
   Token *	$secret.api_token

   • OAuth 2.0: Performs an OAuth 2.0 token exchange. After retrieval, the resulting access token is injected into the request.

   Field	Example
   Client ID *	$global.slack_client_id
   Client secret *	$secret.slack_client_secret
   Access token *	$secret.slack_access_token
   Refresh token *	$secret.slack_refresh_token
   Token URL *	https://slack.com/api/oauth.v2.access
   Authorization URL *	https://slack.com/oauth/v2/authorize
   Token scopes	chat:write

   - Proxy

   Configure how the node connects to external services when a proxy is required.

   Nodes support three modes:

   • Disabled: No proxy is applied. All requests are sent directly.

   • Default: Uses the global proxy settings defined in TheHive application.conf. See proxy configuration in TheHive.

   • Enabled: Defines a custom proxy for this node, overriding the global configuration.

   Field	Example
   Protocol	https
   Address *	proxy.example.com
   Port	8080
   Proxy username	$global.proxy_user
   Proxy password	$secret.proxy_password

   Protocol defaults to https, and Port defaults to 8080.

   - SSL

   Configure SSL settings for secure SSL/TLS communication with external services.

   Use this section when the external service relies on a private certificate authority (CA), requires mutual TLS (client certificate authentication), or uses a non-standard trust chain.

   Field	Description
   Client certificate (mTLS)	Enable to authenticate with a client certificate (mutual TLS). Turned off by default.
   SSL key (PEM)	The private key associated with the client certificate, in PEM format. Required only when Client certificate (mTLS) is enabled.
   SSL certificate (PEM)	The client certificate to present during the SSL/TLS handshake, in PEM format. Required only when Client certificate (mTLS) is enabled.
   Certificate Authorities	Server certificate verification mode. Default: uses the system's pre-installed certificate authorities. Custom: provide a CA certificate to verify the server. Disabled: skips server identity verification. Not recommended in production, as it exposes the connection to security risks.
   SSL CA certificate (PEM)	The CA certificate used to verify the server's identity, in PEM format. Required only when Certificate Authorities is set to Custom.

   - Timeout & retry

   Configure how the node handles execution time limits and failure recovery.

   If no timeout is configured, the node runs until it completes or the workflow-level timeout is reached. If the timeout is reached, the node fails.

   Global timeout vs. local timeout

   A timeout for the entire workflow is defined when creating the workflow. When both a node timeout and a workflow-level timeout are defined, the shortest timeout value is applied.

   Field	Description
   Timeout	Maximum allowed execution time for the node, in seconds, minutes, or hours. The minimum value is 30 seconds.
   Retry attempts	Number of times the node is retried on failure.
   Retry delay	Time to wait between retry attempts, in seconds, minutes, or hours. Always set it when retry attempts are configured: without a delay, retries are effectively never scheduled.
   Backoff	Coefficient applied to the retry delay to increase the wait time after each failed attempt.

   Retries and timeouts

   If the node includes retry settings, the timeout applies to each attempt, not to the total duration of all attempts.

   - Execution configuration

   Set the Execution mode to control how the node behaves when several branches converge on it.

   Mode	Behavior
   Execute once per branch	The node runs once for each incoming branch. Applies when this section is not configured.
   Wait for all branches	The node waits for all incoming branches to complete, then runs once.

8. Optional: Turn on Ignore HTTP errors to make the node succeed regardless of the response status code.

   By default, the node fails when the response returns a 4xx or 5xx error status code. With the option on, handle errors in the workflow, for example with an If flow node evaluating the code output. Transport failures, such as DNS, connection, TLS, or timeout errors, still fail the node.

Execution outputs

When executed, the node returns the following outputs. Each output is a JSON value:

Output	Type	Description
body	object	The response body returned by the API. Not set for a multipart response: use parts instead.
code	number	The HTTP status code returned by the server.
headers	object	The response headers returned by the server.
parts	object	The parts of a multipart response body, keyed by part name. Each part carries its filename, content_type, size, and content. Empty when the response isn't multipart.

A body that is large or binary, and a part content that is large or not JSON, are stored as files and returned as file references. A part stored as a file also carries a sha256sum field, and a part name reused across parts is suffixed with _2, _3, and so on.

To access outputs, select your HTTP request node and then select in the top-right corner of the screen. Hover over each output name to view its details.

These outputs can then be reused as output variables in subsequent nodes, using the $var button or by typing $ and selecting the output from the suggestions. Inserted references are displayed in the following form:

• $<node_name>.body.<field_name>: to get a nested value from the response body
• $<node_name>.code: to get the HTTP status code, for example to check whether the request succeeded
• $<node_name>.headers.<header_name>: to get a specific response header
• $<node_name>.parts.<part_name>.content: to get the content of one part of a multipart response

Configure a Send email action node

A Send email action node sends an email using the SMTP configuration defined in TheHive.

Prerequisite

Before using a Send email action node, you must configure an SMTP server in TheHive. The node can't send emails without a working SMTP configuration.

1. Go to the Flow view from the sidebar menu.

   

2. Select a workflow from the list.

3. Drag the previous node connector to an empty area of the canvas.

   

4. In the What is the next step? drawer, select Actions.

5. Select Send email.

6. In the Send email drawer, enter the following information:

   Variables

   Insert a variable with the $var button, or type $ and select a variable from the suggestions. To access a field, select the variable to edit its jq expression, or use the + button to insert the variable and the field together.

   Fields marked with * are mandatory.

   - From *

   The email address used as the sender.

   - To *

   One or more recipient addresses, separated by commas.

   - Cc

   Additional recipients.

   - Bcc

   Hidden recipients.

   - Subject

   The email subject.

   - Body format

   Choose how the message body is sent:

   • Text
   • HTML
   • Both: Sends both versions. This is the default, and it's recommended for maximum compatibility with email clients.

   - Text body

   The plain text content of the email.

   - HTML body

   The HTML content of the email.

7. Optional: Select Add options to configure the following settings.

   - Timeout & retry

   Configure how the node handles execution time limits and failure recovery.

   If no timeout is configured, the node runs until it completes or the workflow-level timeout is reached. If the timeout is reached, the node fails.

   Global timeout vs. local timeout

   A timeout for the entire workflow is defined when creating the workflow. When both a node timeout and a workflow-level timeout are defined, the shortest timeout value is applied.

   Field	Description
   Timeout	Maximum allowed execution time for the node, in seconds, minutes, or hours. The minimum value is 30 seconds.
   Retry attempts	Number of times the node is retried on failure.
   Retry delay	Time to wait between retry attempts, in seconds, minutes, or hours. Always set it when retry attempts are configured: without a delay, retries are effectively never scheduled.
   Backoff	Coefficient applied to the retry delay to increase the wait time after each failed attempt.

   Retries and timeouts

   If the node includes retry settings, the timeout applies to each attempt, not to the total duration of all attempts.

   - Execution configuration

   Set the Execution mode to control how the node behaves when several branches converge on it.

   Mode	Behavior
   Execute once per branch	The node runs once for each incoming branch. Applies when this section is not configured.
   Wait for all branches	The node waits for all incoming branches to complete, then runs once.

Configure a Slack Send message action node

A Slack - Send message action node sends a message to a Slack channel using a Slack authentication token.

1. Go to the Flow view from the sidebar menu.

   

2. Select a workflow from the list.

3. Drag the previous node connector to an empty area of the canvas.

   

4. In the What is the next step? drawer, select Actions.

5. Select Slack - Send message.

6. In the Slack - Send message drawer, enter the following information:

   Variables

   Insert a variable with the $var button, or type $ and select a variable from the suggestions. To access a field, select the variable to edit its jq expression, or use the + button to insert the variable and the field together.

   Fields marked with * are mandatory.

   - Token *

   The Slack authentication token used to send the message. You may provide either a bot token or a user token, as long as it includes the chat:write permission. See the Slack token documentation for details on token types and required scopes.

   - Channel *

   The Slack channel where the message is posted. Enter the channel ID or name.

   - Markdown

   Enable this option to format your message using Markdown. When turned off, the message is sent as plain text.

   - Text *

   The content of the message.

7. Optional: Select Add options to configure the following settings.

   - Proxy

   Configure how the node connects to external services when a proxy is required.

   Nodes support three modes:

   • Disabled: No proxy is applied. All requests are sent directly.

   • Default: Uses the global proxy settings defined in TheHive application.conf. See proxy configuration in TheHive.

   • Enabled: Defines a custom proxy for this node, overriding the global configuration.

   Field	Example
   Protocol	https
   Address *	proxy.example.com
   Port	8080
   Proxy username	$global.proxy_user
   Proxy password	$secret.proxy_password

   Protocol defaults to https, and Port defaults to 8080.

   - Timeout & retry

   Configure how the node handles execution time limits and failure recovery.

   If no timeout is configured, the node runs until it completes or the workflow-level timeout is reached. If the timeout is reached, the node fails.

   Global timeout vs. local timeout

   A timeout for the entire workflow is defined when creating the workflow. When both a node timeout and a workflow-level timeout are defined, the shortest timeout value is applied.

   Field	Description
   Timeout	Maximum allowed execution time for the node, in seconds, minutes, or hours. The minimum value is 30 seconds.
   Retry attempts	Number of times the node is retried on failure.
   Retry delay	Time to wait between retry attempts, in seconds, minutes, or hours. Always set it when retry attempts are configured: without a delay, retries are effectively never scheduled.
   Backoff	Coefficient applied to the retry delay to increase the wait time after each failed attempt.

   Retries and timeouts

   If the node includes retry settings, the timeout applies to each attempt, not to the total duration of all attempts.

   - Execution configuration

   Set the Execution mode to control how the node behaves when several branches converge on it.

   Mode	Behavior
   Execute once per branch	The node runs once for each incoming branch. Applies when this section is not configured.
   Wait for all branches	The node waits for all incoming branches to complete, then runs once.

Configure a Teams Send message action node

A Teams - Send message action node sends a message to a Microsoft Teams channel using an incoming webhook URL.

1. Go to the Flow view from the sidebar menu.

   

2. Select a workflow from the list.

3. Drag the previous node connector to an empty area of the canvas.

   

4. In the What is the next step? drawer, select Actions.

5. Select Teams - Send message.

6. In the Teams - Send message drawer, enter the following information:

   Variables

   Insert a variable with the $var button, or type $ and select a variable from the suggestions. To access a field, select the variable to edit its jq expression, or use the + button to insert the variable and the field together.

   Fields marked with * are mandatory.

   - Webhook URL *

   The Microsoft Teams incoming Webhook URL associated with the target channel. To create one, see Microsoft official documentation on configuring incoming webhooks.

   - Message *

   The text content of the message to send. Supports a Markdown subset: **bold**, *italics*, and line breaks.

7. Optional: Select Add options to configure the following settings.

   - Proxy

   Configure how the node connects to external services when a proxy is required.

   Nodes support three modes:

   • Disabled: No proxy is applied. All requests are sent directly.

   • Default: Uses the global proxy settings defined in TheHive application.conf. See proxy configuration in TheHive.

   • Enabled: Defines a custom proxy for this node, overriding the global configuration.

   Field	Example
   Protocol	https
   Address *	proxy.example.com
   Port	8080
   Proxy username	$global.proxy_user
   Proxy password	$secret.proxy_password

   Protocol defaults to https, and Port defaults to 8080.

   - Timeout & retry

   Configure how the node handles execution time limits and failure recovery.

   If no timeout is configured, the node runs until it completes or the workflow-level timeout is reached. If the timeout is reached, the node fails.

   Global timeout vs. local timeout

   A timeout for the entire workflow is defined when creating the workflow. When both a node timeout and a workflow-level timeout are defined, the shortest timeout value is applied.

   Field	Description
   Timeout	Maximum allowed execution time for the node, in seconds, minutes, or hours. The minimum value is 30 seconds.
   Retry attempts	Number of times the node is retried on failure.
   Retry delay	Time to wait between retry attempts, in seconds, minutes, or hours. Always set it when retry attempts are configured: without a delay, retries are effectively never scheduled.
   Backoff	Coefficient applied to the retry delay to increase the wait time after each failed attempt.

   Retries and timeouts

   If the node includes retry settings, the timeout applies to each attempt, not to the total duration of all attempts.

   - Execution configuration

   Set the Execution mode to control how the node behaves when several branches converge on it.

   Mode	Behavior
   Execute once per branch	The node runs once for each incoming branch. Applies when this section is not configured.
   Wait for all branches	The node waits for all incoming branches to complete, then runs once.

Configure an Analyzer action node

An Analyzer action node triggers a Cortex analyzer on a specific observable and makes the resulting report available as an output variable for use in subsequent workflow steps.

Prerequisite

To use an Analyzer action node, a Cortex server must already be connected to TheHive. If no Cortex instance is configured, follow the instructions in Add a Cortex Server before proceeding.

1. Go to the Flow view from the sidebar menu.

   

2. Select a workflow from the list.

3. Drag the previous node connector to an empty area of the canvas.

   

4. In the What is the next step? drawer, select Actions.

5. Select Analyzer.

6. In the Analyzer drawer, enter the following information:

   Variables

   Insert a variable with the $var button, or type $ and select a variable from the suggestions. To access a field, select the variable to edit its jq expression, or use the + button to insert the variable and the field together.

   Fields marked with * are mandatory.

   - Observable type *

   The type of observable to analyze. Two input modes are available:

   • Form: Select the type from a list.
   • Raw: Provide the type with a variable, when it's only known at runtime from a previous node's output.

   - Observable ID *

   The identifier of the observable to analyze.

   - Analyzer *

   Choose the Cortex analyzer to run.

   Only analyzers compatible with the selected observable type are shown. The observable's TLP and PAP levels are checked at execution time: if they aren't compatible with the analyzer, Cortex returns an error and the node fails.

   The list covers the analyzers of every Cortex instance connected to the organization. You don't select the instance: the node derives it from the analyzer you choose. When several instances host the same analyzer, the node uses the first one and gives no way to choose another. To target a specific instance, use the TheHive integration node with the Run Analyzer on Observable action, which takes the Cortex instance identifier as a value.

7. Optional: Select Add options to configure the following settings.

   - Timeout & retry

   Configure how the node handles execution time limits and failure recovery.

   If no timeout is configured, the node runs until it completes or the workflow-level timeout is reached. If the timeout is reached, the node fails.

   Global timeout vs. local timeout

   A timeout for the entire workflow is defined when creating the workflow. When both a node timeout and a workflow-level timeout are defined, the shortest timeout value is applied.

   Field	Description
   Timeout	Maximum allowed execution time for the node, in seconds, minutes, or hours. The minimum value is 30 seconds.
   Retry attempts	Number of times the node is retried on failure.
   Retry delay	Time to wait between retry attempts, in seconds, minutes, or hours. Always set it when retry attempts are configured: without a delay, retries are effectively never scheduled.
   Backoff	Coefficient applied to the retry delay to increase the wait time after each failed attempt.

   Retries and timeouts

   If the node includes retry settings, the timeout applies to each attempt, not to the total duration of all attempts.

   - Execution configuration

   Set the Execution mode to control how the node behaves when several branches converge on it.

   Mode	Behavior
   Execute once per branch	The node runs once for each incoming branch. Applies when this section is not configured.
   Wait for all branches	The node waits for all incoming branches to complete, then runs once.

Execution output

When executed, the node runs the selected analyzer on the observable. The analyzer’s report is available as an output object.

To access the output, select your Analyzer node and then select in the top-right corner of the screen. Hover over the output name to view its details.

This output can then be reused as an output variable in subsequent nodes, using the $var button or by typing $ and selecting the output from the suggestions. The inserted reference is displayed as $<node_name>.analyzer_report.

It contains the full report returned by Cortex, in the format specific to the analyzer that was run. Use a Set local variable node, a JavaScript code node, or a Python code node to extract specific fields from it.

Configure a Responder action node

A Responder action node triggers a Cortex responder on a specific alert, case, observable, task, or task log. When the node runs, it executes the selected responder and makes the resulting report available as an output variable for use in subsequent workflow steps.

Prerequisite

To use a Responder action node, a Cortex server must already be connected to TheHive. If no Cortex instance is configured, follow the instructions in Add a Cortex Server before proceeding.

1. Go to the Flow view from the sidebar menu.

   

2. Select a workflow from the list.

3. Drag the previous node connector to an empty area of the canvas.

   

4. In the What is the next step? drawer, select Actions.

5. Select Responder.

6. In the Responder drawer, enter the following information:

   Variables

   Insert a variable with the $var button, or type $ and select a variable from the suggestions. To access a field, select the variable to edit its jq expression, or use the + button to insert the variable and the field together.

   Fields marked with * are mandatory.

   - Entity type *

   The type of entity on which the responder should run: an alert (alert), a case (case), an observable (case_artifact), a task (case_task), or a task log (case_task_log).

   Two input modes are available:

   • Form: Select the type from a list. The list is built from the entity types declared by the responders of the connected Cortex instances, so a type appears only when at least one enabled responder supports it.
   • Raw: Enter the type directly or provide it with a variable, when it's only known at runtime from a previous node's output or missing from the list.

   - Entity ID *

   The identifier of the entity to process.

   - Responder *

   Choose the Cortex responder to execute.

   Only responders compatible with the selected entity type are shown. The entity's TLP and PAP levels are checked at execution time: if they aren't compatible with the responder, Cortex returns an error and the node fails.

7. Optional: Select Add options to configure the following settings.

   - Timeout & retry

   Configure how the node handles execution time limits and failure recovery.

   If no timeout is configured, the node runs until it completes or the workflow-level timeout is reached. If the timeout is reached, the node fails.

   Global timeout vs. local timeout

   A timeout for the entire workflow is defined when creating the workflow. When both a node timeout and a workflow-level timeout are defined, the shortest timeout value is applied.

   Field	Description
   Timeout	Maximum allowed execution time for the node, in seconds, minutes, or hours. The minimum value is 30 seconds.
   Retry attempts	Number of times the node is retried on failure.
   Retry delay	Time to wait between retry attempts, in seconds, minutes, or hours. Always set it when retry attempts are configured: without a delay, retries are effectively never scheduled.
   Backoff	Coefficient applied to the retry delay to increase the wait time after each failed attempt.

   Retries and timeouts

   If the node includes retry settings, the timeout applies to each attempt, not to the total duration of all attempts.

   - Execution configuration

   Set the Execution mode to control how the node behaves when several branches converge on it.

   Mode	Behavior
   Execute once per branch	The node runs once for each incoming branch. Applies when this section is not configured.
   Wait for all branches	The node waits for all incoming branches to complete, then runs once.

Execution output

When executed, the node runs the selected responder on the selected alert, case, observable, or task. The responder’s report is available as an output object.

To access the output, select your Responder node and then select in the top-right corner of the screen. Hover over the output name to view its details.

This output can then be reused as an output variable in subsequent nodes, using the $var button or by typing $ and selecting the output from the suggestions. The inserted reference is displayed as $<node_name>.responder_report.

It contains the full report returned by Cortex, in the format specific to the responder that was run. Use a Set local variable node, a JavaScript code node, or a Python code node to extract specific fields from it.

Configure an AI action node

An AI action node sends a message to a large language model (LLM) and returns its response. Use it to triage alerts, summarize case data, classify observables, or draft content as part of a workflow. The node calls an OpenAI-compatible LLM provider configured by your administrator.

Prerequisite

An administrator must configure at least one LLM provider before using an AI action node.

1. Go to the Flow view from the sidebar menu.

   

2. Select a workflow from the list.

3. Drag the previous node connector to an empty area of the canvas.

   

4. In the What is the next step? drawer, select Actions.

5. Select AI.

6. In the AI drawer, enter the following information:

   Variables

   Insert a variable with the $var button, or type $ and select a variable from the suggestions. To access a field, select the variable to edit its jq expression, or use the + button to insert the variable and the field together.

   Fields marked with * are mandatory.

   - Role and context

   Defines the posture and context the AI adopts. For example: You are a security analyst specialized in alert triage.

   - Message *

   The concrete instruction to execute. Phrase the request here and inject the data to analyze from upstream nodes, for example Analyze this alert and decide whether to escalate or discard: $input.alert.

   - Provider *

   The LLM provider to use. Available providers depend on the configuration set by your administrator.

   - Model *

   The model that generates the response, selected from the models available for the chosen provider.

   - Output schema

   A JSON schema describing the expected output structure. When set, the AI constrains its response to match the schema, so downstream nodes can consume the fields individually. The field opens pre-filled with a schema declaring a single message string field. You can clear it: when the field is empty, no result output is produced and only the raw response text is available.

7. Optional: Select Add options to configure the following sections.

   - Model parameters

   Temperature: Controls how random the response is, from 0 to 2. Lower values make the response more focused and deterministic. Higher values make it more varied. Leave empty to use the model default.

   Max tokens: The maximum number of tokens in the response. Leave empty to use the provider default.

   Reasoning effort: How much reasoning the model spends before answering: None, Minimal, Low, Medium, High, Extra high, or Max. None turns reasoning off, and the levels a model accepts depend on the provider. Leave empty to use the configuration default, then the provider default.

   - Timeout & retry

   Configure how the node handles execution time limits and failure recovery.

   If no timeout is configured, the node runs until it completes or the workflow-level timeout is reached. If the timeout is reached, the node fails.

   Global timeout vs. local timeout

   A timeout for the entire workflow is defined when creating the workflow. When both a node timeout and a workflow-level timeout are defined, the shortest timeout value is applied.

   Field	Description
   Timeout	Maximum allowed execution time for the node, in seconds, minutes, or hours. The minimum value is 30 seconds.
   Retry attempts	Number of times the node is retried on failure.
   Retry delay	Time to wait between retry attempts, in seconds, minutes, or hours. Always set it when retry attempts are configured: without a delay, retries are effectively never scheduled.
   Backoff	Coefficient applied to the retry delay to increase the wait time after each failed attempt.

   Retries and timeouts

   If the node includes retry settings, the timeout applies to each attempt, not to the total duration of all attempts.

   - Execution configuration

   Set the Execution mode to control how the node behaves when several branches converge on it.

   Mode	Behavior
   Execute once per branch	The node runs once for each incoming branch. Applies when this section is not configured.
   Wait for all branches	The node waits for all incoming branches to complete, then runs once.

Execution outputs

When executed, the node returns the following outputs. Each output is a JSON value:

Output	Type	Description
response	string	The raw text response from the LLM.
result	object	The parsed structured output. Present only when an output schema is set.
message	object	The raw assistant message returned by the LLM, including reasoning content when the model provides it.
tool_calls	array	The tool calls requested by the model, when the LLM answers with tool calls instead of text.
finish_reason	string	The reason the LLM stopped generating, for example stop, length, tool_calls, or content_filter.
usage	object	Token usage for the call: prompt_tokens, completion_tokens, and total_tokens.

To access outputs, select your AI node and then select in the top-right corner of the screen. Hover over each output name to view its details.

These outputs can then be reused as output variables in subsequent nodes, using the $var button or by typing $ and selecting the output from the suggestions. Inserted references are displayed in the following form:

• $<node_name>.response: to get the text response
• $<node_name>.result.<field_name>: to get a field from the structured output when an output schema is set
• $<node_name>.finish_reason: to check why the LLM stopped generating, for example in an If condition
• $<node_name>.usage.total_tokens: to get the total token usage of the call

Next steps

• Manage Global Variables
• Add a Trigger
• Configure an Integration Node
• Configure a Transformation Node
• Configure a Flow Node
• Manually Run a Workflow