Keep Your Enterprise SOAP Services From Quietly Breaking With Dotcom-Monitor SOAP API Monitoring

Continuous testing of SOAP-based web services from outside your infrastructure. Validates that the service is reachable and responsive, that the XML envelope is well-formed, that XPath assertions pass, and that the response conforms to the WSDL contract — and alerts your team the moment any of those break.

Yes. Drop in a WSDL 1.1 or 2.0 file. Dotcom-Monitor parses operations, port types, bindings, and message schemas, then generates request templates so you can run monitors against any operation without hand-coding XML envelopes.

Yes — WS-Security with X.509 certificate signing, UsernameToken, SAML token, message-level encryption, and timestamp validation. Plus mTLS at the transport layer for client certificate auth.

Both. SOAP 1.1 (text/xml content type with SOAPAction header) and SOAP 1.2 (application/soap+xml) are fully supported, with correct content negotiation per binding.

Configure XPath expressions to evaluate against the response envelope, header, or any node. The monitor fails if an assertion returns an unexpected value, a missing node, or a wrong type. Common patterns: //transaction/status = 'approved' or count(//errors) = 0.

A SOAP fault returns HTTP 200 with a <soapenv:Fault> element inside the envelope — uptime monitors miss it entirely. We check explicitly for the Fault element and surface the faultcode and faultstring in the alert payload.

SOAP validates XML envelopes via XPath instead of JSON via JSONPath, parses WSDL contracts rather than OpenAPI specs, and handles enterprise auth schemes (WS-Security, SAML, mTLS) that are common in SOAP services. The underlying platform — global locations, multi-step chains, alerting, Private Agents — is shared. See REST API monitoring →

Yes. Deploy Private Agents inside your network — common for internal enterprise integration buses, on-prem service catalogs, and regulated environments. Outbound-only connection, no inbound firewall rules.

Long-lived integrations in banking, insurance, healthcare (HL7-via-SOAP, FHIR over SOAP), government, and ERP. SOAP’s strict WSDL contracts, the WS-* security stack, and transaction guarantees remain valuable in regulated environments. Replacing them with REST is rarely worth the risk — monitoring keeps them visible alongside modern services.

Yes. WS-Addressing headers (Action, To, MessageID, ReplyTo) can be set explicitly per request or imported automatically from a WSDL when the binding requires them.

Yes. MTOM/XOP attachment requests and responses are supported, including binary payload validation against expected size or content-type constraints.

The same as any other SOAP endpoint — point a monitor at the published WSDL URL or directly at the endpoint URL with a request envelope. For internal-only services, deploy a Private Agent inside the network where the integration bus runs.

Each failed run captures the full request envelope, response envelope (or socket-level error if the endpoint was unreachable), HTTP headers, timing breakdown (DNS, TLS, server processing), the specific XPath assertion that failed, and the SOAP fault if returned.