SOAP APIs are a lot more resilient to change than REST APIs, often because they carry more metadata about their operations and data types.
Let’s see how Postman can help you wrangle a SOAP API. Imagine we’ve got a simple calculator service.
First, we need the WSDL. That’s the Web Services Description Language document. It’s basically the API’s blueprint. You’ll usually find it at a URL like http://example.com/calculator?wsdl.
In Postman, create a new request. For the method, select POST. The URL will be the endpoint of your service, often the same as the WSDL URL but without the ?wsdl part. So, http://example.com/calculator.
Now, the crucial part: the request body. For SOAP, this is always XML. You’ll structure it like this:
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<YourOperationName xmlns="http://example.com/">
<Parameter1>Value1</Parameter1>
<Parameter2>Value2</Parameter2>
</YourOperationName>
</soap:Body>
</soap:Envelope>
The YourOperationName and the parameters inside it are defined in the WSDL. For our calculator, let’s say we want to Add. The WSDL would tell us it takes two integers.
So, the body might look like this for adding 5 and 3:
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<Add xmlns="http://example.com/">
<IntA>5</IntA>
<IntB>3</IntB>
</Add>
</soap:Body>
</soap:Envelope>
Crucially, you need to set the Content-Type header to text/xml; charset=utf-8. Some services might also require SOAPAction in the headers, which is often an empty string or a URI pointing to the operation. Check your WSDL for this.
When you send this, the response will also be XML, and it will be wrapped in SOAP envelope tags.
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<AddResponse xmlns="http://example.com/">
<AddResult>8</AddResult>
</AddResponse>
</soap:Body>
</soap:Envelope>
To make this easier, Postman has a built-in WSDL importer. Go to File > Import, select Link, paste your WSDL URL, and Postman will often generate the collection, including requests for each operation and sample XML bodies.
The xmlns attributes are critical. They define the XML namespace, which tells the server which version of a schema your XML conforms to. If these don’t match what the service expects, you’ll get errors. The soap namespace is standard for SOAP envelopes, but the namespace for your actual operation (like http://example.com/ in our example) is specific to the service.
When you’re dealing with complex types or arrays in your SOAP request, you’ll need to replicate that structure in XML. For instance, a list of strings might look like this within your operation tag:
<MyStringArray>
<string>item1</string>
<string>item2</string>
<string>item3</string>
</MyStringArray>
If you’re writing tests in Postman, you’ll use pm.response.xml() to parse the SOAP response and then query it using XPath. For example, to get the AddResult from our previous response:
const responseXml = pm.response.xml();
const addResult = responseXml.xpath('//AddResult')[0].text();
console.log('Add Result:', addResult);
pm.expect(parseInt(addResult)).to.eql(8);
The xpath() method returns an array of matching elements, so you usually grab the first one [0] and then access its text content.
The most common pitfall is namespace mismatch. If the xmlns in your request body doesn’t align with what the WSDL specifies for the operation and its elements, the server won’t understand your request. Always cross-reference your XML with the WSDL.
One thing that often trips people up is how to handle optional or null values. In SOAP, you typically omit the element entirely if it’s null or not provided. If the service expects a specific null representation (like xsi:nil="true"), you’d add that to the element tag, but omitting it is more common and often preferred.
The next hurdle you’ll likely face is dealing with SOAP Faults, which are the SOAP equivalent of API errors, and understanding how to correctly construct requests for more intricate data types like nested objects or enumerations.