Available on SaaS with FlowX.AI . 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.WSDL import
Import from a URL or an uploaded file; operations, schemas, and the service URL are discovered automatically
Typed operations
Each operation carries its input, output, and fault schemas from the WSDL’s XSD, browsable as a data-model tree
Composed envelopes
FlowX composes the SOAP envelope at runtime; you work with
${variable} placeholders, not raw XMLBuilt-in testing
Test operations with per-variable overrides and a curl preview before wiring them into workflows
Creating a SOAP System data source
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.
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.Configure authorization
On the Settings tab, configure the Authorization used for outgoing calls — the same authorization methods available to REST systems. See Configuring authorization.
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
.wsdlor.xmlfile, up to 5 MB. - Paste URL — a WSDL URL (for example
https://intra.acme.local/service?wsdl) that FlowX fetches and parses.
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. |
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<soap:Header>, 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.
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).
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
Integration Designer
Data sources, workflows, and REST integrations
Receiving XML and SOAP responses
Calling SOAP services through a plain REST endpoint (available on all deployments)