Skip to main content
The SOAP node lets you connect your flow to SOAP web services, a common protocol in legacy and enterprise systems. It’s a real execution node: it makes the request and exposes success and error outputs to continue the flow, just like the API node.
The SOAP node shares its credentials and execution infrastructure with the API node — if you’re already familiar with that node, this configuration will feel familiar too.

​
Basic configuration

  • URL — the SOAP service’s address.
  • Operation Name — the name of the SOAP operation you want to invoke (free text; it isn’t validated against a WSDL).
Both the URL and the Operation Name are required — the node is marked invalid if either is left empty.
The HTTP method is always POST.

​
Namespaces

Define the SOAP envelope’s namespaces in a reorderable table (drag to change the order): You can use workflow variables when defining the URI.

​
Headers

Add custom headers as key-value pairs.
The Content-Type header is managed automatically based on the SOAP version you choose in Settings, and can’t be edited manually.

​
Body

The request body is edited in a free-form code editor (JSON or XML). The node doesn’t visually build the SOAP envelope — the final envelope is assembled by the execution engine.

​
Authentication

Three options available:

​
Settings

  • SOAP version — 1.1 or 1.2. Changing it automatically rewrites the Content-Type header.
  • Timeout — in milliseconds, defaults to 30000 (30s).
  • Response transformation — extract only the part of the response you need by defining an extractPath (for example, GetUserResponse.Data).

​
Advanced

​
Hold the conversation while waiting

By default, while the node waits for the service to respond, the user is free: if they write, their message is handled by the project router and can start another flow in the same conversation. To prevent this, open the Advanced tab and enable Hold the conversation while waiting: the user stays in this workflow until the request finishes.
Messages the user sends while the conversation is held do not enter the flow: they are always discarded, so later nodes —including an AI Agent— will not see what they wrote.

​
How long it lasts

The conversation is released as soon as the request finishes, through either the success or the error output, and the flow continues. As a safeguard, the hold lasts at most the timeout configured in Settings; if you did not set one, it lasts 60 seconds. It never exceeds 1 hour.

​
When it does not apply

  • Nodes inside a Tool: only the workflow that talks to the user can hold them, so the option is ignored on a SOAP node running inside a Tool. In that case, enable it on the workflow’s Tool node; see What is a Tool.
  • Conversations with an operator: if a human agent takes over the conversation, their messages bypass the hold.
  • User already held: if another node —for example, a Pause or a Tool with the same option— is already holding the user, that hold is kept and this node does not replace it.

​
Save the response

Enable “Save response” and define a variable name to store the SOAP service’s response.

​
Access the response from a Code node

You can also read the original request with $context.getSoapRequest('myVariable'). Both accessors support .headers() and .json(); getSoapResponse also includes .status().

​
Test the request

The “Send” button runs the request and shows the result: status code, and Body and Headers tabs for the response, with a copy-to-clipboard option.

​
Error handling

The node exposes two outputs: success and error. Connect the error output to the next step that should handle the failure, without interrupting the rest of the flow.