SOAP Client
Developer ToolsBuild correctly namespaced SOAP 1.1 or 1.2 envelopes, post them to any endpoint, and parse the reply. Agents reach the legacy enterprise services that never got a REST interface.
What This Integration Enables
Somewhere in most established companies there is a system that everything depends on and nothing can talk to. A claims platform, a core banking ledger, a state licensing registry, a warehouse management system from before REST won. It exposes SOAP, its documentation is a WSDL, and the people who know it well are the people you cannot get time with. That system is not a legacy problem to be migrated around. It is where the transactions actually land, and an agent that cannot reach it can only ever do the easy half of the work.
This connector reaches it. Give it an endpoint and the contents of the Body element and it wraps them in a correctly namespaced SOAP 1.1 or 1.2 envelope, sets the matching Content-Type and SOAPAction, posts it, and parses the reply into a plain object with the raw XML alongside. Or skip the XML entirely: give it an operation name, a namespace and a plain object of arguments, and it builds the request element for you, mapping nested objects to nested elements, arrays to repeated elements, and keys beginning with an at sign to attributes. It reads a WSDL to discover what a service offers and generates a request skeleton for a single operation. It supports HTTP Basic and WS-Security UsernameToken with plain text or digest passwords, where digest keeps the password off the wire. Faults are never returned as success, and external entity resolution is disabled outright, so a document declaring a DOCTYPE is rejected rather than parsed. This is plumbing, and it is the kind of plumbing that decides whether a connector strategy reaches the systems that matter or stops at the ones with a modern API.
Without FlowRunner
With FlowRunner
Use Case Scenarios
Posting a transaction into a system with no test environment
An approved credit memo needs to reach a claims platform that exposes a single SOAP endpoint and has no sandbox. The flow calls Get WSDL Operation to retrieve the operation's SOAP action, style, endpoint address and a request skeleton generated from the inline schema. It fills the skeleton, calls Build SOAP Envelope to produce the exact XML that would go on the wire, and checks that the WS-Security header is present and the endpoint matches the production address in the WSDL. Only after the system owner reads the envelope and releases it does Send SOAP Request post the transaction. When the reply comes back it is parsed into a plain object, and if the service returns a fault instead, the flow raises an error carrying the fault code, reason, actor and detail rather than continuing on a phantom success.
Bridging a SOAP back end into a modern flow
A logistics partner pushes shipment status as raw SOAP envelopes to a webhook. The flow receives the envelope as text and calls Parse SOAP Response, which returns the body payload, the SOAP header and the name of the response element, recognising both SOAP 1.1 and 1.2 regardless of which namespace prefix the sender used and unwrapping any CDATA sections. The extracted status is written to PostgreSQL and a delivery exception is posted to Slack. No SOAP knowledge is required anywhere else in the flow, because the envelope stops being XML at the first step. Nothing has to be sent for this to work, which also makes Parse SOAP Response the safe way to work on a captured payload while debugging.
Mapping an unfamiliar government service before committing to it
A team needs to file returns against a state agency service and has nothing but a WSDL URL. A flow calls Get WSDL Summary, which returns the target namespace, every service and port with its endpoint address, every binding with its transport and style, and every operation with its SOAP action, message names and documentation. That becomes a table the team can actually read and argue over: which operations we need, which we must never call, which look like they were deprecated in place. Get WSDL Operation then fills in one operation at a time. It is worth knowing the limit here: imported WSDL and schema documents are listed but not followed, and the generated skeleton expands only one level deep, so genuinely nested types still need the schema in front of a person.
Human-in-Loop Highlight
The connector ships a build-but-do-not-send action, and that is not a convenience feature. Build SOAP Envelope returns the complete envelope and the transport headers as text, makes no network request, authenticates nothing and validates nothing, which makes it exactly the right thing to put in front of a human when the next call cannot be taken back. Legacy enterprise services are frequently the ones with no sandbox, no dry-run flag and no reversal operation; a posted journal entry, a filed return or a submitted claim is simply done. The tooling also tells you honestly that it cannot fully check the payload, because the skeleton from Get WSDL Operation stops one level deep and does not follow imported schemas. So for any operation flagged as a commit, the agent builds the envelope and posts the text into the change channel, together with the endpoint address it resolved and the authentication mode it would use. Then it asks the system owner: "This posts credit memo CM-4471 for 12,480.00 to the claims endpoint at the production address. There is no reversal operation on this service. Send, or hold for manual entry?" The digital andon cord is pulled between building the request and sending it, which is the only place in this workflow where stopping is still free. That gap is where human-in-the-loop earns its keep.
Agent Capabilities
6 actionsSending Requests
2- Send SOAP Request Sends a raw SOAP request to any endpoint you supply and returns the parsed response. You provide the contents of the Body element as XML and the service wraps it in a correctly namespaced SOAP 1.1 or 1.2 envelope, sets the matching Content-Type and SOAPAction, and posts it. The response envelope is parsed into a plain object with the raw XML alongside it. A SOAP Fault always raises an error carrying the fault code, reason, actor and detail, including when the service delivers it with an HTTP 500. Supports HTTP Basic and WS-Security UsernameToken authentication with plain text or digest passwords. This action posts to whatever URL it is given, so treat the endpoint as you would any server-side request target and do not build it from untrusted input.
- Call SOAP Operation Calls a SOAP operation without writing any XML by hand. You give the operation name, its namespace and the arguments as a plain object, and the service builds the request element, wraps it in a correctly namespaced envelope, posts it and parses the reply. Nested objects become nested elements, arrays repeat an element, and a key beginning with an at sign becomes an attribute on the enclosing element. A SOAP Fault always raises an error rather than being returned as a successful result. Use Send SOAP Request instead when the body needs a structure this mapping cannot express.
Envelope Construction and Parsing
2- Build SOAP Envelope Builds a complete SOAP 1.1 or 1.2 envelope and returns it as text without sending anything, so you can inspect exactly what would go on the wire, hand it to a colleague to reproduce a problem, or post it yourself from another step. Accepts either raw body XML or an operation name with a parameters object, and can include a WS-Security UsernameToken header with a plain text or digest password. The transport headers that would accompany the request are returned alongside the envelope. No network request is made, so nothing is authenticated or validated against a schema.
- Parse SOAP Response Parses a SOAP envelope that is already in the flow, captured from a webhook, read from a file or returned by another step, into a plain object without sending anything. The body payload, the SOAP header and the name of the response element are all returned. A SOAP Fault raises an error carrying the fault code, reason, actor and detail, so a fault can never be mistaken for a successful reply. Both SOAP 1.1 and 1.2 envelopes are recognised regardless of which namespace prefix the sender used, and CDATA sections are unwrapped. External entity resolution is disabled: an envelope declaring a DOCTYPE is rejected rather than parsed.
WSDL Discovery
2- Get WSDL Summary Downloads a WSDL document and summarises what the service offers: the target namespace, every service and port with its endpoint address, every binding with its transport and style, and every operation with its SOAP action, input and output message names and documentation. Use it to discover an unfamiliar service, to find the endpoint URL and SOAP action a call needs, or to check that a deployment exposes the operations you expect. Imported WSDL and schema documents are listed by location but are not followed, so operations defined only in an imported file will not appear.
- Get WSDL Operation Downloads a WSDL document and returns everything needed to call one operation: its SOAP action, style, endpoint address, target namespace, the parts of its input and output messages, and a ready-to-edit request skeleton you can paste straight into Send SOAP Request. The skeleton is generated one level deep from the inline schema, listing the immediate child elements of the request type with their declared types as comments; deeply nested or imported types are not expanded, so complex operations still need the schema to hand.
Frequently Asked Questions
What can FlowRunner do with SOAP Client?
FlowRunner agents can run Send SOAP Request, Call SOAP Operation, and Build SOAP Envelope in SOAP Client, plus 3 more actions.
Does connecting SOAP Client to FlowRunner require OAuth?
SOAP Client uses a custom authentication method to connect to FlowRunner.
Can SOAP Client trigger a FlowRunner workflow automatically?
SOAP Client doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with SOAP Client
$100 in credits. No card required. Connect in minutes.