> ## Documentation Index
> Fetch the complete documentation index at: https://docs.flowx.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# SOAP System
> Connect FlowX workflows to SOAP web services by importing a WSDL, then invoke the discovered operations as workflow nodes.
export const release_0 = "5.10"
SaaS · {release_0}
**Available on SaaS with FlowX.AI {release_0}.** This feature is live on managed (SaaS) deployments now. Self-hosted deployments receive it with the next LTS release.
## Overview
The **SOAP System** data source connects Integration Designer to SOAP web services. Instead of hand-building envelopes through a REST endpoint, you import the service's **WSDL** — FlowX parses it into typed operations with input, output, and fault schemas — and call the discovered operations from workflows like any other data-source operation.
Import from a URL or an uploaded file; operations, schemas, and the service URL are discovered automatically
Each operation carries its input, output, and fault schemas from the WSDL's XSD, browsable as a data-model tree
FlowX composes the SOAP envelope at runtime; you work with `${variable}` placeholders, not raw XML
Test operations with per-variable overrides and a curl preview before wiring them into workflows
Both **SOAP 1.1** and **SOAP 1.2** services are supported. The SOAP version is derived from the WSDL and is read-only.
***
## Creating a SOAP System data source
In **Data Sources**, create a new data source and pick **SOAP System** (under the **APIs** category, next to Restful System). Give it a name and description.
On the system page, set the **Service URL** — the endpoint the SOAP calls are sent to. The field supports configuration parameters, so you can write `https://${environment}.example.com/service` and vary it per environment. Importing a WSDL fills this in automatically when the WSDL declares a service address.
On the **Settings** tab, configure the **Authorization** used for outgoing calls — the same authorization methods available to REST systems. See [Configuring authorization](./integration-designer#configuring-authorization).
On the **Operations** tab, click **Import from WSDL** to discover the service's operations (next section).
***
## Importing a WSDL
Operations are created **only** through WSDL import — there is no manual "add operation". The **Import WSDL** modal offers two sources:
* **Upload file** — a `.wsdl` or `.xml` file, up to 5 MB.
* **Paste URL** — a **WSDL URL** (for example `https://intra.acme.local/service?wsdl`) that FlowX fetches and parses.
Click **Preview** to fetch and parse the document. The preview shows the **Service URL detected** in the WSDL, the list of discovered operations (each as *name — SOAPAction*) with **Select all / Deselect all**, and any parser **Warnings**. Select the operations you want and click **Import**.
**Re-importing.** When the system already has operations, the modal becomes **Re-import WSDL**. Re-importing refreshes the WSDL-derived parts of each operation (the locked WSDL operation name, SOAPAction, and schemas) — your display names, descriptions, and other edits are preserved.
***
## Configuring an operation
Each imported operation has a details page. The WSDL-derived identity — **WSDL operation** and **SOAPAction** — is locked and refreshed on re-import; everything else is yours to configure:
| Property | Description |
| ---------------- | ------------------------------------------------------------------------------------------------------------------ |
| **Display name** | A friendly name for the operation (3–50 characters). Renaming does not change the underlying WSDL operation. |
| **Description** | Optional free text. |
| **Timeout** | Maximum time in milliseconds to wait for a response before aborting the SOAP call. Applies to this operation only. |
| **URL source** | **Service URL** (the system-level URL) or **Endpoint URL override** for this operation. |
**Show schemas** opens the operation's **Input**, **Output**, and **Fault** schemas as a browsable tree (element names, XSD types, cardinality, and documentation from the WSDL).
### Variables
The **Envelope** tab lists the operation's **Variables** — auto-extracted from the input XSD. Reference each as `${variableName}` in the envelope or SOAP header XML.
* **XSD-derived variables** are contract-locked: you can set a **Default value** and **Description**, but the key, type, and required flag come from the WSDL.
* **User-defined variables** can be added freely (key, XSD type, default, required) — useful for values referenced from the SOAP header XML.
### SOAP header XML
Toggle **SOAP header XML** on to provide a custom header block. It is injected verbatim into ``, and `${variableName}` placeholders are substituted from the variables above.
### Envelope preview and HTTP headers
The **Envelope preview** shows the full SOAP envelope FlowX composes and sends at runtime, with variables shown as `${variableName}` placeholders — read-only, composed server-side.
The **Http Headers** tab adds custom headers to the outgoing HTTP request that wraps the envelope (for example `Authorization: Bearer ${token}`). The standard SOAP headers are derived automatically: SOAP 1.1 sends `Content-Type: text/xml` plus the `SOAPAction` header; SOAP 1.2 sends `Content-Type: application/soap+xml` with no SOAPAction header.
***
## Testing an operation
The **Test** button opens a test modal where you can:
* Enter per-variable values that replace `${variableName}` placeholders for this test run.
* Optionally override the **SOAP header XML** for this invocation only.
* Inspect the derived standard headers (tagged *from SOAP 1.1 / 1.2* and *from WSDL*) and set per-test header values.
* Copy a backend-generated **curl** preview that includes your current overrides.
The response panel shows the **Status**, **Time**, and **Size**, with the body viewable as **XML** or parsed **JSON**. A SOAP fault is rendered distinctly with its fault code, string, actor, and detail.
You can also test an operation against a **build**: in the builds list, use **Test SOAP operation** from the build's menu and pick the operation.
***
## Using in workflows
Add a **SOAP Operation** node (under **Data Operations** in the workflow node palette) and select the operation, searching by system or operation name. The node:
* Exposes the operation's variables as parameters, with per-node value overrides.
* Stores the parsed response under the node's **response key**, like a REST call.
* Has a **Settings** tab with a per-node **Timeout** and **Allow Retry** options (retry count, interval, exponential backoff).
**Failure semantics:** a non-2xx response fails the node with the real HTTP status; **SOAP faults are not retried** (they are contract errors, not transient failures); an unreachable service surfaces as a 503.
The workflow **run logs** show, per attempt, the system, operation, SOAPAction, URL, and SOAP version, with the full **request and response envelopes** expandable — retried attempts are logged separately.
***
## Current limitations
* **WS-Security is not supported.** For services that require credentials, use the system-level **Authorization** and custom HTTP or SOAP headers.
* **File and binary payloads are not supported** — operations exchange XML data only.
* Operations cannot be created manually; they always come from a WSDL import.
***
## Related resources
Data sources, workflows, and REST integrations
Calling SOAP services through a plain REST endpoint (available on all deployments)