> ## 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. ## 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. > [card] WSDL import > > Import from a URL or an uploaded file; operations, schemas, and the service URL are discovered automatically > [card] Typed operations > > Each operation carries its input, output, and fault schemas from the WSDL's XSD, browsable as a data-model tree > [card] Composed envelopes > > FlowX composes the SOAP envelope at runtime; you work with `${variable}` placeholders, not raw XML > [card] Built-in testing > > 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 **1. Create the 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. **2. Set the Service URL** 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. **3. Configure authorization** On the **Settings** tab, configure the **Authorization** used for outgoing calls — the same authorization methods available to REST systems. See [Configuring authorization](https://docs.flowx.ai/6.x/docs/platform-deep-dive/integrations/integration-designer.md#configuring-authorization). **4. Import the WSDL** 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**. > [!NOTE] > > **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 > [card] [Integration Designer](https://docs.flowx.ai/6.x/docs/platform-deep-dive/integrations/integration-designer.md) > > Data sources, workflows, and REST integrations > [card] [Receiving XML and SOAP responses](https://docs.flowx.ai/6.x/docs/platform-deep-dive/integrations/integration-designer.md#receiving-xml-and-soap-responses) > > Calling SOAP services through a plain REST endpoint (available on all deployments) ## Related topics - [FlowX.AI 5.10.0 Release Notes](https://docs.flowx.ai/release-notes/v5.x/v5.10.0-july-2026/v5.10.0-july-2026.md) - [Integration Designer](https://docs.flowx.ai/6.x/docs/platform-deep-dive/integrations/integration-designer.md) - [Choose how to connect FlowX.AI to external systems](https://docs.flowx.ai/6.x/docs/platform-deep-dive/integrations/integrations-overview.md) - [Testing data sources from Runtime](https://docs.flowx.ai/6.x/docs/platform-deep-dive/integrations/testing-data-sources.md) - [Builds](https://docs.flowx.ai/6.x/docs/projects/runtime/builds.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.