SOAP is not dead. It is not trendy, it is not what startups choose for greenfield projects, and it does not appear in conference keynotes. But it powers the backbone of industries that cannot afford to move fast and break things.
The numbers tell the story: SOAP still handles approximately $9 trillion per day in banking transactions and accounts for roughly 15% of APIs in banking, healthcare, and ERP systems. 55% of large organizations continue to run SOAP services alongside REST. These are not legacy systems waiting to be replaced — they are critical infrastructure that processes real money, real health records, and real government transactions every second.
But the ground is shifting. Microsoft Dynamics 365 Business Central started deprecating SOAP endpoints in April 2025, with full removal planned for 2026. Oracle NetSuite announced that their 2025.2 SOAP endpoint is the last — all SOAP endpoints will be disabled with the 2028.2 release. Salesforce retired API versions 21.0-30.0 in June 2025. The writing is on the wall: enterprises need to test their SOAP services rigorously now, while simultaneously planning migrations to REST, gRPC, or GraphQL.
The irony is that while REST APIs enjoy a rich ecosystem of modern testing tools, SOAP testing tooling has barely evolved in a decade.
The SOAP Testing Toolbox in 2026
Here is what is actually available today, honestly assessed.
SoapUI Open Source (Free)
Still the industry standard 21 years after its release. SoapUI parses WSDLs, generates sample requests for all operations, supports WS-Security and WS-Addressing, and lets you build functional test suites with Groovy scripting.
What it does well: WSDL import is solid. Schema compliance assertions validate responses against the WSDL-defined output types. WS-I Basic Profile compliance checking catches interoperability issues. If you need to test a SOAP service and you have zero budget, SoapUI works.
What it does not do: The free version lacks meaningful automation support — no data-driven testing from external sources, limited property transfer between steps, no CI/CD integration without manual scripting, and no service virtualization. The Java Swing UI has not been updated in years. Newer developers who grew up with Postman find it painful to use.
ReadyAPI (SmartBear, from $599/year)
The commercial evolution of SoapUI adds data-driven testing, service virtualization, security scanning (SQL injection, fuzzing, XSS), and proper CI/CD integration. If your organization tests SOAP services seriously, this is what most teams end up buying.
The reality check: $599/year per user for the base license. Performance testing starts at $6,449/year for 250 virtual users. Enterprise pricing is opaque. For a team of five, you are looking at $3,000-$30,000/year depending on what you need.
Postman
Postman added WSDL import (both 1.1 and 2.0) and can generate SOAP request objects within collections. For simple SOAP services, it works.
The gotcha: Users on GitHub have reported that Postman's generated XML requests from WSDL differ from those generated by SoapUI and python-zeep. Complex type handling is weaker than dedicated SOAP tools. WS-Security requires manual header construction. If your WSDL has deep type hierarchies, multiple schema imports, or WS-Security policies, Postman will frustrate you.
JMeter (Free)
JMeter handles SOAP through HTTP Request samplers (the dedicated SOAP sampler was deprecated in JMeter 3.0). Strength is in load and performance testing of SOAP services, not functional testing. You manually configure Content-Type and SOAPAction headers. For stress-testing a SOAP endpoint under load, JMeter is still the go-to free option.
Parasoft SOAtest (~$56,000/year suite)
The enterprise heavyweight. Supports 120+ protocols and message formats, offers built-in service virtualization (Parasoft Virtualize), and added AI-augmented test generation in 2025. If your organization has the budget and tests SOAP services across multiple environments with complex WS-* security policies, SOAtest is the most capable tool available.
The barrier: Pricing is not published, but reported averages are around $56,000/year for the suite. The licensing structure is complex. This is a tool for organizations that spend seven figures on QA infrastructure.
python-zeep
Worth mentioning because it is what many teams actually use in practice. Python's zeep library lets you programmatically interact with WSDL services in CI pipelines without a GUI. Write pytest tests that call SOAP operations, assert on responses, and run in any CI environment. No license fees. Full control. But you are writing and maintaining all the test logic yourself.
Why SOAP Testing Is Harder Than REST Testing
If you have only tested REST APIs, SOAP testing will surprise you. These are not theoretical problems — they are what practitioners deal with daily.
XML Namespace Hell
About 40% of SOAP interoperability challenges involve namespace conflicts. A single mismatched namespace prefix or missing declaration produces an opaque SOAP Fault. The error message rarely tells you which namespace is wrong — just that the XML is invalid.
A typical SOAP request might reference three or four namespaces: the SOAP envelope namespace, the service's target namespace, one or more imported schema namespaces, and potentially WS-Security namespaces. Getting all of them right across all test payloads is a constant source of bugs.
WSDL Complexity
Enterprise WSDLs are not simple files. They import dozens of XSD schemas, define hundreds of complex types with inheritance and restrictions, and describe 50+ operations. A WSDL for a banking payment service might be 15,000 lines across 30 imported schema files. Navigating this to understand what a single operation expects is a non-trivial exercise.
WS-Security
WS-Security adds message-level security: timestamps, username tokens, X.509 certificate signing, SAML assertions, XML encryption. Setting up keystores, certificates, and token generation for test environments is a multi-day exercise. Most legacy security scanners cannot support SOAP API security testing at all, as noted in a 2026 Levo.ai industry review.
Many teams fall back to partial security (TLS only, skipping message signing and timestamp checks), which creates security gaps in test environments that do not match production behavior.
No Modern Contract Testing
For REST APIs, Pact provides mature consumer-driven contract testing. For SOAP? Pact can technically work (SOAP operates over HTTP), but it was designed for JSON. You lose WSDL-aware validation, schema compliance checking, and namespace handling. There is no mature, widely-adopted contract testing ecosystem for SOAP comparable to what REST developers enjoy.
AI-Powered SOAP Testing
The recent wave of AI testing tools has largely ignored SOAP. Most AI testing platforms focus on web UI and REST APIs. This makes sense commercially — that is where the growth is — but it leaves SOAP teams underserved.
A few tools are starting to address this gap.
TestSprite markets itself as an AI-powered SOAP testing tool that generates tests from WSDL, executes in cloud environments, and provides AI debugging. They claim benchmark improvements of 42% to 93% pass rates after one iteration compared to raw LLM-generated code. This is a newer entrant worth watching but too early to assess in production.
Qate treats SOAP as a first-class citizen alongside REST and web testing. The approach:
-
Import the WSDL — the AI parses the full WSDL and all referenced XSD schemas. For large WSDLs (common in enterprise), it splits the spec into batches of up to 80,000 characters, keeping shared schema definitions intact across batches.
-
Generate test suites — for each operation, the AI generates complete SOAP envelopes with proper namespaces, soapAction headers, and realistic sample values. Tests cover five categories: positive (happy path), negative (missing required elements), edge case (boundary values), security (malformed inputs), and performance.
-
Execute with auth support — SOAP tests execute via HTTP POST with
Content-Type: text/xmland the correct SOAPAction header. Qate supports NTLM authentication natively (critical for many enterprise SOAP services behind Windows auth), plus OAuth, API key, and generic auth definitions. -
Validate against the WSDL — responses are checked for SOAP Fault elements and validated against the operation's output schema.
The same CLI and CI/CD integration works for both REST and SOAP:
- name: Run SOAP regression tests
env:
QATE_API_KEY: ${{ secrets.QATE_API_KEY }}
run: |
qate run -n "Payment Service SOAP Tests" --wait --junit results/soap.xml
For teams using the CLI locally, qate export generates standalone Vitest + Axios test files for SOAP services — not Playwright (which cannot do SOAP), but standard HTTP test code with XML assertions that run anywhere.
Practical Advice
If You Are Starting from Zero
Use SoapUI Open Source to import your WSDL and get familiar with the service. It is free and the WSDL parsing is battle-tested over two decades. Use it to manually explore operations and understand the service contract. Then decide whether SoapUI's test suite capabilities are sufficient or whether you need something more automated.
If Maintenance Is Killing You
The biggest time sink in SOAP testing is not writing the initial tests — it is keeping them current as the WSDL evolves. When an operation's input type gains a new required field, every test for that operation breaks. When a namespace changes, everything breaks.
Automated test generation from the WSDL (whether through AI or through SoapUI's built-in generation) dramatically reduces this burden. Re-importing an updated WSDL and regenerating tests takes minutes instead of hours of manual XML editing.
If You Test Both REST and SOAP
Most enterprise applications expose both. Testing them in separate tools (Postman for REST, SoapUI for SOAP) means separate CI integrations, separate reporting, and separate maintenance workflows. Consolidating into a single platform — whether that is ReadyAPI, Katalon, Parasoft, or Qate — reduces operational complexity.
If You Are Planning a SOAP-to-REST Migration
Your SOAP tests become your safety net. As you build REST equivalents of SOAP operations, the SOAP tests validate that the migration preserves behavior. Run both suites against the new REST endpoints (with an adapter layer) to catch regressions. Do not decommission SOAP tests until the migration is complete and verified.
The Bigger Picture
SOAP is not going away tomorrow. Oracle's deprecation timeline extends to 2028. Microsoft's to 2026. SWIFT just completed its XML messaging migration in November 2025. Government and healthcare systems are measured in decades, not product cycles. The CMS FHIR mandate does not even take full effect until 2027.
If your organization runs SOAP services — and statistically, most large organizations do — investing in proper testing now pays dividends whether you are maintaining these services for the long term or migrating them to modern alternatives. Either way, the tests need to exist, and they need to be maintainable.
The tooling gap between REST and SOAP is real, but it is narrowing. The entry of AI-powered tools into the SOAP testing space means teams no longer have to choose between SoapUI's dated interface and writing custom test harnesses from scratch. That alone is progress worth acknowledging.