The PolyApiIDE SOAP workspace takes a WSDL file, builds the request envelope and shows Fault responses in a way that makes it obvious where the schema and your body disagree.
SOAP is alive wherever enterprise and public-sector integrations are: ministry exchanges, banking gateways, long-lived ESB layers. The format is unforgiving about detail — one wrong Content-Type or an empty SOAPAction and the service answers with a Fault instead of data.
That is why SOAP is a separate workspace type here: WSDL is imported, operations are listed, and environments hold the addresses and credentials of each stage.
It is an HTTP POST with an XML body. The body holds an Envelope, which contains an optional Header and a mandatory Body with the operation call. The SOAP version decides both the envelope namespace and the transport headers.
SOAP 1.1 uses the namespace http://schemas.xmlsoap.org/soap/envelope/, Content-Type: text/xml; charset=utf-8 and a separate SOAPAction header whose value comes from soapAction in the WSDL binding and is quoted. SOAP 1.2 uses http://www.w3.org/2003/05/soap-envelope, application/soap+xml; charset=utf-8, and carries the action as an action parameter inside Content-Type rather than as its own header. Half of all mysterious rejections come down to mixing those two sets.
WSDL import is included in the free plan. The service address, the operation list and the SOAPAction values are taken from the description, which removes most of the manual typing and the typos that come with it.
The body follows the WSDL schema. Watch the namespace prefixes and the element order: in XML Schema the order inside a sequence is significant, so swapping two fields is as much an error as omitting a required one.
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<ns:GetBalance xmlns:ns="urn:example:billing">
<ns:account>{{account}}</ns:account>
</ns:GetBalance>
</soap:Body>
</soap:Envelope>
SOAP 1.1 needs Content-Type: text/xml; charset=utf-8 and a non-empty SOAPAction. SOAP 1.2 needs application/soap+xml; charset=utf-8 with the action parameter. Take the version from the WSDL rather than guessing.
Keep stage addresses, logins, account numbers and request ids in environments and reference them with {{var}} — substitution works inside the XML body as well. One request then serves both test and production with no edits to the envelope.
A SOAP error arrives as an envelope containing a Fault element, usually with HTTP status 500. In 1.1 read faultcode and faultstring; in 1.2 read Code/Value and Reason/Text. A value of soap:Client (soap:Sender in 1.2) means the request is at fault, soap:Server means the service broke.
| Symptom | Likely cause | What to do |
|---|---|---|
| HTTP 415 | Server expects a different Content-Type | text/xml for SOAP 1.1, application/soap+xml for 1.2 |
| Fault about SOAPAction | Header empty or wrong | Take soapAction from the WSDL binding; quote it in 1.1 |
| Fault with faultcode soap:Client | Body failed schema validation | Required elements, order inside sequence, value types |
| Fault about an unexpected element | Wrong namespace or prefix | Match the operation targetNamespace to the envelope |
| HTTP 200 with an empty Body | One-way operation | Check whether the WSDL defines a response at all |
| HTTP 401 or 403 | Rejected at the gateway, never reached the service | Credentials, channel certificate, IP allow list |
A large share of our users work with government and corporate APIs where SOAP is still the primary format. The extension covers the transport side: WSDL import, envelope, headers, per-stage environments, repeatable operation checks and response history, all of it stored locally in the browser.
What it does not do — worth saying before you install: the extension does not create digital signatures and does not assemble MTOM attachments. If your regulation requires signed XML, the envelope is signed by an external tool and the ready body is pasted into the client. For state exchange integrations we keep a separate page.
No. WSDL import and sending SOAP requests are available on Free, with no sign-up. Paid plans cover scenarios, load testing, PDF reports and collection patches.
No. The signature is produced by your cryptographic tooling and the already signed envelope is sent from PolyApiIDE. Claiming otherwise would be dishonest.
From the WSDL binding, and from the envelope namespace. http://schemas.xmlsoap.org/soap/envelope/ is 1.1; http://www.w3.org/2003/05/soap-envelope is 1.2.
After import the operations land in a collection that you can split into folders, keeping only the calls you actually use. Sample files to practise on are on the examples page.
No, the extension does not build MTOM multipart payloads. Operations without attachments work normally.