SOAP has not gone away. Banking systems, payment gateways, government services, and older enterprise platforms still expose SOAP endpoints, and someone has to test them. If you have spent your career on REST and JSON, a SOAP service can feel foreign. The protocol is stricter, the payloads are XML, and the contract lives in a separate WSDL file.
The good news is that testing a SOAP API online is not hard once you understand what it actually wants from you. This guide explains how SOAP testing differs from REST testing, walks through a real request, and covers the online tools that handle SOAP without fighting you.
Why SOAP testing is different
REST is a style. SOAP is a protocol with rules. That distinction shapes everything about how you test it.
A SOAP message is always an XML document wrapped in an envelope. The envelope has a header for metadata like authentication or routing, and a body that holds the actual operation and its parameters. You cannot just send a loose JSON object. The structure is mandatory, and a malformed envelope is rejected before your logic ever runs. SOAP also nearly always travels over HTTP POST, even for operations that only read data, and it expects a specific Content-Type, usually text/xml or application/soap+xml.
The biggest practical difference is the WSDL. A WSDL, or Web Services Description Language file, is a machine-readable contract that lists every operation the service offers, the exact shape of each request and response, and the endpoint address. REST rarely ships anything this strict. When you test SOAP, the WSDL is your map. A good online SOAP tester reads the WSDL and generates request templates for you, so you are not hand-typing envelopes from memory. If you want the broader contract picture, our notes on API contract testing explain why a strict contract is an asset.
What a SOAP request actually looks like
Here is a realistic SOAP request against a currency conversion service. Notice the envelope, the namespace declarations, and the operation nested in the body.
POST /CurrencyService.asmx HTTP/1.1
Host: rates.example.com
Content-Type: text/xml; charset=utf-8
SOAPAction: "https://rates.example.com/ConvertAmount"
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:cur="https://rates.example.com/">
<soap:Header>
<cur:AuthToken>e9f2a1c7-4b8d-4c2a-9f31-7d6e5a4b3c21</cur:AuthToken>
</soap:Header>
<soap:Body>
<cur:ConvertAmount>
<cur:FromCurrency>USD</cur:FromCurrency>
<cur:ToCurrency>EUR</cur:ToCurrency>
<cur:Amount>250.00</cur:Amount>
</cur:ConvertAmount>
</soap:Body>
</soap:Envelope>
The response comes back wrapped the same way:
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:cur="https://rates.example.com/">
<soap:Body>
<cur:ConvertAmountResponse>
<cur:ConvertAmountResult>231.45</cur:ConvertAmountResult>
</cur:ConvertAmountResponse>
</soap:Body>
</soap:Envelope>
Two details trip people up. The SOAPAction HTTP header is required by many services and must match the operation, or you get a fault. And when something fails, SOAP does not return an HTTP 400 with a tidy message. It returns HTTP 200 with a <soap:Fault> element inside the body. Your test has to parse the body to know whether the call truly succeeded. Checking the status code alone is not enough, which is one reason structured API assertions matter more here than in REST.
Online tools for testing SOAP APIs
Apidog
Apidog handles SOAP alongside REST, GraphQL, and WebSocket in one place. You import a WSDL, and it generates the request structure so you are not building envelopes by hand. You can add assertions on XML elements, chain requests into a scenario, and run the whole thing as an automated suite. Because it also designs and mocks APIs, you can mock a SOAP response before the real service is ready. Download Apidog to test SOAP services on the free tier.
SoapUI
SoapUI is the original SOAP testing tool and still the deepest. Point it at a WSDL and it builds a project with every operation. The open-source edition is free and strong for functional and data-driven SOAP tests. It is a heavier Java desktop application, and the most polished reporting features sit in the paid ReadyAPI tier. For a closer look, see what SoapUI is and how it works.
Postman
Postman can send SOAP requests. You set the body to raw XML, add the Content-Type and SOAPAction headers manually, and paste your envelope. It works, but Postman does not parse a WSDL, so you build envelopes yourself. It is fine for a one-off check and less comfortable for a large SOAP surface.
Browser-based SOAP testers
Several lightweight web tools let you paste a WSDL URL and fire requests from a browser tab. They are handy for a quick verification with nothing installed. The limits show up fast: thin assertion support, little or no automation, and no way to organize a real test suite. Use them to confirm an endpoint is alive, not to build a regression suite.
A quick SOAP testing workflow
- Get the WSDL. Most SOAP services expose it by appending
?wsdlto the endpoint URL. Open it and confirm it loads. - Import the WSDL into your tool. Apidog and SoapUI generate request templates from it. This is the single biggest time saver.
- Fill in the operation parameters. Use real values. Test a currency conversion with an actual amount and valid currency codes.
- Set the headers. Confirm
Content-Typeand, when required,SOAPAction. A missingSOAPActionis the most common cause of an unexplained fault. - Send and inspect the body. Do not stop at the HTTP status. Open the response body and check for
<soap:Fault>. - Add assertions. Assert that a specific element exists and holds the expected value. Then chain a follow-up call if your flow needs it.
For organizing these into a maintainable set, our guide on building test suites for API automation applies directly to SOAP work.
SOAP faults and how to assert on them
A SOAP fault is the protocol’s error structure. It carries a faultcode, a faultstring, and sometimes a detail element. Because it arrives with an HTTP 200, a test that only checks status will pass on a failed call. That is a silent, dangerous false positive.
Write your SOAP assertions to look inside the body. Assert that no <soap:Fault> element is present on a success path. On a deliberate error path, assert the opposite, that the fault appears and the faultcode matches what you expect. Testing the failure cases is as important as the happy path, because SOAP services often encode business rules, like a declined transaction, as faults rather than data. The W3C SOAP fault documentation describes the structure if you need the formal detail.
WS-Security adds another layer. Many enterprise SOAP services expect a signed or token-bearing security header. If your requests fail with an authentication fault, the WSDL or the service docs will say which security profile is in play. Tools like SoapUI and Apidog let you configure these headers rather than hand-rolling the XML.
Reading a WSDL without getting lost
A WSDL file looks intimidating the first time you open one. It is long, deeply nested XML, and most of it is machine plumbing. You do not need to read all of it. Four parts carry the information you actually want.
The types section defines the data structures, usually as XML Schema, so this is where you learn the exact shape and constraints of each parameter. The message elements describe the input and output for each operation. The portType lists the operations themselves, which are the calls you can make. The service and binding sections give the concrete endpoint address and the transport details. When you import a WSDL into a tool, it reads all four and turns them into ready-to-edit requests, which is why importing beats hand-typing every time.
One detail worth knowing: a WSDL can split across multiple files using import statements, often pulling schemas in from separate locations. If your tool reports a missing type, a referenced file probably failed to resolve. Make sure every imported URL is reachable from where your tool runs. This kind of contract dependency is exactly why teams treat the WSDL as a versioned artifact rather than something that lives only on a server.
Data-driven SOAP testing
SOAP services often carry strict business rules, and a single happy-path request rarely proves much. A currency service should be tested with valid pairs, with an unsupported currency, with a zero amount, and with a negative amount. A payment service should be tested with an approved card, a declined card, and an expired one. Typing each of these by hand is slow and easy to get wrong.
Data-driven testing solves this. You write the request once with placeholders, then feed it a table of input rows and expected outcomes. The tool runs the request for every row and checks each result. SoapUI has supported this pattern for years, and Apidog supports it through its scenario runner. The payoff is real coverage of the edge cases that SOAP services tend to encode as faults. For the broader pattern, our guide on data-driven API testing with CSV and JSON explains how to structure the input data, and it applies to SOAP just as it does to REST.
Frequently asked questions
What is the difference between SOAP and REST testing?
SOAP testing works against a strict XML protocol with a WSDL contract, mandatory envelopes, and faults returned inside an HTTP 200 body. REST testing usually deals with JSON, looser conventions, and meaningful HTTP status codes. A SOAP test must parse the response body to confirm success; a REST test can often trust the status code.
Do I need the WSDL to test a SOAP API?
You can send a SOAP request without it if you already know the exact envelope structure. But the WSDL makes testing far easier because tools generate correct request templates from it. Most services expose the WSDL by adding ?wsdl to the endpoint URL. Always start there.
Why does my SOAP request return a fault even though the status is 200?
SOAP reports errors as a <soap:Fault> element inside the body, not as an HTTP error code, so a 200 with a fault is normal. The usual causes are a missing or wrong SOAPAction header, a malformed envelope, a namespace mismatch, or a failed security check. Read the faultstring for the specific reason.
Can I test SOAP APIs online for free?
Yes. Apidog supports SOAP on its free tier and imports WSDL files, and the open-source edition of SoapUI is built for SOAP. Lightweight browser testers also exist for quick checks, though they lack real assertion and automation support.
How do I automate SOAP API tests?
Import the WSDL, build a scenario that chains the operations in order, add assertions on response elements and on fault absence, then run it from a tool’s runner or in your CI pipeline. SoapUI and Apidog both support scheduled and pipeline-triggered SOAP suites, so a SOAP regression run fits the same automation flow as REST.