WSDL and SOAP: how to create and mock a SOAP API online (no code)

If you've ever had to integrate with a SOAP API, you know the pain. XML everywhere, cryptic WSDL files, and a local mock server that takes 45 minutes to set up before you can write a single line of code.

In this guide I'll explain what WSDL and SOAP actually are, how they relate to each other, and how you can mock a SOAP API in seconds — without touching your terminal.

---

What is SOAP?

SOAP (Simple Object Access Protocol) is a protocol for exchanging structured information between services. Unlike REST, which uses plain JSON over HTTP, SOAP uses XML for every request and response, and follows a strict contract defined in a WSDL file.

It was the dominant API standard in the 2000s and early 2010s. Today it's still widely used in:

• Banking and financial systems
• Government services
• Enterprise software (SAP, Oracle, legacy ERP systems)
• Healthcare (HL7 integrations)

If you work in any of these industries, you will encounter SOAP. There's no way around it.

---

What is WSDL?

WSDL (Web Services Description Language) is an XML document that describes a SOAP web service. Think of it as the contract between the server and the client.

A WSDL file defines:

• Types — the data structures used (like a schema)
• Messages — what gets sent and received
• PortType — the operations available (like endpoints)
• Binding — how the operations are transmitted (SOAP, HTTP, etc.)
• Service — where the service lives (the URL)

Here's a minimal example of what a WSDL looks like:

<definitions name="HelloService"
  targetNamespace="http://example.com/hello"
  xmlns="http://schemas.xmlsoap.org/wsdl/"
  xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
  xmlns:tns="http://example.com/hello"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema">

  <message name="SayHelloRequest">
    <part name="firstName" type="xsd:string"/>
  </message>

  <message name="SayHelloResponse">
    <part name="greeting" type="xsd:string"/>
  </message>

  <portType name="Hello_PortType">
    <operation name="sayHello">
      <input message="tns:SayHelloRequest"/>
      <output message="tns:SayHelloResponse"/>
    </operation>
  </portType>

  <binding name="Hello_Binding" type="tns:Hello_PortType">
    <soap:binding style="rpc"
      transport="http://schemas.xmlsoap.org/soap/http"/>
    <operation name="sayHello">
      <soap:operation soapAction="sayHello"/>
      <input><soap:body use="literal"/></input>
      <output><soap:body use="literal"/></output>
    </operation>
  </binding>

  <service name="Hello_Service">
    <port name="Hello_Port" binding="tns:Hello_Binding">
      <soap:address location="http://example.com/hello"/>
    </port>
  </service>

</definitions>

Reading this for the first time is overwhelming. The good news: once you understand the structure, it's repetitive — and you can mock it without understanding every detail.

---

What is a SOAP request?

When a client calls a SOAP service, it sends an HTTP POST with an XML body called a SOAP envelope. Here's what a request to the sayHello operation above looks like:

<soapenv:Envelope
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:hel="http://example.com/hello">
  <soapenv:Header/>
  <soapenv:Body>
    <hel:sayHello>
      <firstName>John</firstName>
    </hel:sayHello>
  </soapenv:Body>
</soapenv:Envelope>

And the response:

<soapenv:Envelope
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Body>
    <greeting>Hello, John!</greeting>
  </soapenv:Body>
</soapenv:Envelope>

Every SOAP call follows this envelope structure. The actual payload lives inside <soapenv:Body>.

---

Why mock a SOAP API?

There are several common situations where you need a SOAP mock:

1. The real service isn't ready yet
Your backend team is still building the SOAP service. You need to develop and test your integration now, not in 3 weeks.

2. The real service is expensive or rate-limited
Some SOAP APIs charge per call or have strict rate limits. Running your test suite against the real thing is costly.

3. The real service is flaky or slow
External SOAP services can be unreliable. A mock gives you a stable, fast endpoint for CI/CD pipelines.

4. You need to simulate error scenarios
Try getting a real banking API to return a timeout on demand. With a mock, you control every response.

---

The traditional way: painful

Most developers mock SOAP APIs using one of these tools:

WireMock — powerful but requires Java, a local JVM, and significant XML configuration. Getting a SOAP mock running takes 30–60 minutes minimum.

SoapUI — feature-rich but heavyweight. The free version is limited, and the setup is not lightweight.

Writing your own server — some teams spin up a simple Node.js or Python server that returns hardcoded XML. Works, but requires maintenance and isn't shareable.

All of these approaches share the same problem: they live on your machine. You can't share a URL with your team, you can't use it in a CI environment without extra setup, and every developer needs to set it up independently.

---

The modern way: mock in the browser

MockHub is a cloud-based mock server that supports both REST and SOAP APIs. No install, no Java, no terminal.

Here's how to mock a SOAP API on MockHub:

Step 1 — Create a new API

Sign up for free at mockhub.ovh and click New API. Give it a name like HelloService.

Step 2 — Add a SOAP endpoint

Set the method to POST and the path to /hello. This is where your mock will listen.

Step 3 — Set the response

In the response body, paste the SOAP XML you want to return:

<soapenv:Envelope
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Body>
    <greeting>Hello, {{firstName}}!</greeting>
  </soapenv:Body>
</soapenv:Envelope>

Notice {{firstName}} — MockHub supports dynamic variables, so the mock can echo back values from the request or generate random data.

Step 4 — Copy the URL and test it

MockHub gives you a live URL immediately. Test it with curl:

curl -X POST https://mockhub.ovh/api/your-mock-id/hello \
  -H "Content-Type: text/xml" \
  -d '<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
        <soapenv:Body>
          <hel:sayHello>
            <firstName>John</firstName>
          </hel:sayHello>
        </soapenv:Body>
      </soapenv:Envelope>'

You get back a proper SOAP response instantly. No local server, no Java, no configuration files.

---

Bonus: import an OpenAPI spec

If you're working with REST APIs and have an OpenAPI/Swagger spec, MockHub can import it and generate all the mock endpoints automatically. Upload your .yaml or .json file and every path in your spec becomes a working mock endpoint in seconds.

---

SOAP vs REST — quick comparison

	SOAP	REST
Format	XML only	JSON, XML, plain text
Contract	WSDL (mandatory)	OpenAPI (optional)
Transport	Usually HTTP, also SMTP	HTTP only
Error handling	SOAP Fault (structured)	HTTP status codes
Best for	Enterprise, financial, legacy	Modern web and mobile

Neither is universally better. SOAP's strict contract is actually an advantage in high-stakes integrations where you need guaranteed message structure.

---

Summary

• SOAP is an XML-based protocol still widely used in enterprise systems
• WSDL is the contract file that describes a SOAP service
• Mocking SOAP APIs traditionally requires heavy tooling (WireMock, SoapUI)
• MockHub lets you create SOAP and REST mocks in the browser in seconds, with a shareable URL and no setup

If your team integrates with SOAP services and you're still setting up local mock servers, give MockHub a try — the free plan covers 5 APIs and 40 requests/day, which is enough to get started.

👉 mockhub.ovh

---

Have questions about SOAP mocking or a specific integration scenario? Drop a comment below — happy to help.