Testing SOAP APIs requires specialized tooling. Unlike REST APIs where you can fire off a quick curl command with a JSON body, SOAP demands correctly structured XML envelopes, namespace-aware request construction, and the ability to parse verbose XML responses. The right testing tool can save you hours of manual XML wrangling.
This guide compares the major SOAP testing tools available in 2026, with honest assessments of where each one excels and where it falls short.
1. SoapUI (Open Source)
SoapUI by SmartBear has been the de facto standard for SOAP testing since 2005. It remains the most feature-complete free option.
Strengths
- WSDL import. Point it at a WSDL URL and it auto-generates request templates for every operation, with the correct namespaces and element structure already in place.
- Request validation. Built-in schema validation checks your request against the WSDL before sending.
- Assertions. XPath-based assertions let you validate specific elements in the response.
- Mock services. Generate mock SOAP endpoints from a WSDL for testing without a live server.
Basic Workflow
1. File → New SOAP Project
2. Enter WSDL URL: https://api.example.com/Service?wsdl
3. SoapUI generates request templates for each operation
4. Fill in parameter values
5. Click "Submit" (green play button)
6. Inspect the response in the XML tab
Setting Up Assertions
<!-- Assert that the response contains a specific user ID -->
//tns:GetUserResponse/tns:userId = 42
<!-- Assert that the status is "active" -->
//tns:GetUserResponse/tns:status = 'active'
<!-- Assert that the response has no SOAP fault -->
not(//soap:Fault)
Limitations
- The UI feels dated — it's a Java Swing application that hasn't aged well
- Startup time is slow, especially with large projects
- The open-source version lacks test suites and CI/CD integration
- Plugin ecosystem is limited compared to Postman
SoapUI Pro (ReadyAPI)
The commercial version adds:
- Data-driven testing with CSV/database inputs
- CI/CD integration with Jenkins, Azure DevOps, and GitHub Actions
- Load testing capabilities
- Service virtualization for complex mock scenarios
- Pricing starts at several hundred dollars per year per seat
Best for: Teams with complex SOAP testing needs who want a dedicated, full-featured SOAP testing environment.
2. Postman
Postman is primarily known for REST API testing, but it has supported SOAP since version 7. Its SOAP support is less mature than SoapUI's, but if your team already uses Postman for REST testing, keeping SOAP tests in the same tool has real advantages.
How to Test SOAP in Postman
- Create a new HTTP request
- Set the method to
POST - Set the URL to the SOAP endpoint
- Add headers:
Content-Type: text/xml;charset=UTF-8SOAPAction: "http://example.com/GetUser"(check WSDL for the correct action)
- In the Body tab, select "raw" and "XML"
- Paste your SOAP envelope
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:tns="http://example.com/userservice">
<soap:Body>
<tns:GetUser>
<tns:userId>42</tns:userId>
</tns:GetUser>
</soap:Body>
</soap:Envelope>
Writing Tests in Postman
Postman's test scripts work with SOAP responses, though you'll need to parse XML:
const xml = pm.response.text();
const jsonObject = xml2Json(xml);
pm.test("Response contains user data", function () {
const body = jsonObject["soap:Envelope"]["soap:Body"];
const response = body["tns:GetUserResponse"];
pm.expect(response["tns:userName"]).to.equal("Alice");
});
pm.test("No SOAP fault", function () {
pm.expect(xml).to.not.include("soap:Fault");
});
Limitations
- No WSDL import — you must construct envelopes manually
- No built-in XPath assertions (you parse XML to JSON first)
- Collections with SOAP requests feel awkward alongside REST requests
- Environment variable substitution works but requires inserting variables into raw XML
Best for: Teams already using Postman who need to test a few SOAP endpoints alongside REST APIs.
3. curl
For quick, one-off SOAP requests, curl is hard to beat. No installation, no GUI overhead — just a command.
curl -X POST "https://api.example.com/Service" \
-H "Content-Type: text/xml;charset=UTF-8" \
-H 'SOAPAction: "http://example.com/GetUser"' \
-d '<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:tns="http://example.com/userservice">
<soap:Body>
<tns:GetUser>
<tns:userId>42</tns:userId>
</tns:GetUser>
</soap:Body>
</soap:Envelope>'
Pipe through xmllint for readable output:
curl -s -X POST "https://api.example.com/Service" \
-H "Content-Type: text/xml" \
-d @request.xml | xmllint --format -
Tips for curl SOAP Testing
- Store request bodies in files (
-d @request.xml) instead of inline strings - Use
-vto see the full HTTP exchange including headers - Use
-w "\n%{http_code}\n"to print the HTTP status code - Combine with
jqif you first convert the XML response to JSON
Best for: Quick debugging, CI/CD scripts, and developers who prefer the command line.
4. Insomnia
Insomnia supports SOAP requests in the same way as Postman — set up a POST request with XML body and appropriate headers. It doesn't have WSDL import or SOAP-specific features, but its clean UI and environment management make it pleasant for manual testing.
Best for: Developers who prefer Insomnia's interface and need occasional SOAP testing.
5. VS Code REST Client Extension
The REST Client extension for VS Code lets you send HTTP requests directly from .http files:
### Get User via SOAP
POST https://api.example.com/Service
Content-Type: text/xml;charset=UTF-8
SOAPAction: "http://example.com/GetUser"
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:tns="http://example.com/userservice">
<soap:Body>
<tns:GetUser>
<tns:userId>42</tns:userId>
</tns:GetUser>
</soap:Body>
</soap:Envelope>
Best for: Developers who want to keep test requests in version control alongside their code.
6. Language-Specific Testing
For automated test suites, use your language's testing framework with a SOAP client library:
Node.js with Jest
import soap from "soap";
describe("UserService", () => {
let client;
beforeAll(async () => {
client = await soap.createClientAsync(
"https://api.example.com/Service?wsdl"
);
});
test("GetUser returns user data", async () => {
const [result] = await client.GetUserAsync({ userId: 42 });
expect(result.userName).toBe("Alice");
expect(result.userEmail).toContain("@");
});
test("GetUser with invalid ID returns fault", async () => {
await expect(
client.GetUserAsync({ userId: -1 })
).rejects.toThrow();
});
});
Python with pytest and zeep
import pytest
from zeep import Client
@pytest.fixture
def soap_client():
return Client("https://api.example.com/Service?wsdl")
def test_get_user(soap_client):
result = soap_client.service.GetUser(userId=42)
assert result.userName == "Alice"
def test_get_user_not_found(soap_client):
with pytest.raises(Exception):
soap_client.service.GetUser(userId=-1)
Best for: Teams that need SOAP tests as part of their CI/CD pipeline.
Comparison Table
| Tool | WSDL Import | Assertions | CI/CD | Cost | Learning Curve |
|---|---|---|---|---|---|
| SoapUI (OSS) | Yes | XPath | Limited | Free | Medium |
| SoapUI Pro | Yes | XPath + data-driven | Yes | $$ | Medium |
| Postman | No | JavaScript | Yes | Free / $$ | Low |
| curl | No | Manual | Yes | Free | Low |
| Insomnia | No | Limited | Limited | Free / $ | Low |
| VS Code REST Client | No | No | No | Free | Low |
| Code (Jest/pytest) | Via library | Full | Yes | Free | Medium |
A Different Way to Test SOAP Services
All the tools above require you to understand SOAP envelopes, namespaces, and XML structure. If you've already set up SOAPless to proxy your SOAP service, you can test your SOAP endpoints using any standard REST testing tool with simple JSON payloads. The XML complexity is handled by the proxy — your tests stay clean, readable, and maintainable by any developer on the team.
Whatever testing approach you choose, the key is consistency. Pick a tool, establish patterns for your team, and include SOAP tests in your CI/CD pipeline so regressions are caught early.