How to Mock a SOAP API from a WSDL File — Complete Guide

If you've ever worked with SOAP APIs, you know the drill. You're building a client integration against a partner's payment gateway, an insurance quoting service, or a government reporting system — and the actual SOAP service is either not ready, behind a VPN, rate-limited, or costs money per call. You need a mock SOAP API, and you need it fast.

In this guide, I'll walk you through how to take any WSDL file and turn it into a fully working SOAP mock service in minutes — no code, no server setup, and no XML-wrangling by hand.

---

Why Mocking SOAP APIs Is Harder Than REST

With REST, mocking is relatively straightforward: pick a URL, define a JSON response, and you're done. SOAP is a different beast. A proper SOAP mock needs to:

• Parse a WSDL file to understand the available operations, input/output messages, and XML schemas
• Return valid SOAP XML envelopes — not just any XML, but responses that match the expected message structure
• Listen on a real HTTP endpoint so your application code can point to it without modification
• Handle SOAPAction headers correctly

Building this from scratch means writing XML parsing logic, generating response templates, and hosting the whole thing. Most developers don't have time for that, especially when they just need a working endpoint for testing.

That's where a dedicated SOAP API generator comes in.

---

What You'll Need

Before we start, gather the following:

1. A WSDL file — This is the XML contract that describes the SOAP service. You might have it from a partner, downloaded from a live service's ?wsdl URL, or defined in your project's documentation.

2. A free MockHub account — We'll use MockHub to upload the WSDL and generate the mock service. The free plan supports SOAP mocks with up to 40 API calls per month, which is plenty for development and testing.

3. A SOAP client for testing — This can be SoapUI, Postman, or simply curl. I'll show examples with curl so you can follow along without installing anything extra.

---

Step 1: Upload Your WSDL File

Head over to the MockHub SOAP generator. If you haven't registered yet, create a free account first — it takes about 30 seconds and doesn't require a credit card.

Once you're logged in:

1. Click on the SOAP mock generator page
2. Upload your WSDL file (or paste its contents)
3. MockHub parses every operation defined in the WSDL and auto-generates a fully working SOAP mock endpoint

That's it. No configuration wizards, no XML template authoring. MockHub reads the WSDL, understands the operations and their message structures, and creates a mock service that returns valid SOAP XML responses for every operation.

Your new mock SOAP endpoint will be live immediately at a URL like:

https://mockhub.ovh/mock/{your_user_id}/{endpoint_id}

---

Step 2: Test Your Mock SOAP Endpoint with curl

Let's say your WSDL defines a GetCustomer operation. Here's how you'd test the mock endpoint using curl:

curl -X POST https://mockhub.ovh/mock/example/customer-service \
  -H "Content-Type: text/xml; charset=utf-8" \
  -H "SOAPAction: GetCustomer" \
  -d '<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:cus="http://example.com/customer">
  <soap:Header/>
  <soap:Body>
    <cus:GetCustomerRequest>
      <cus:CustomerId>12345</cus:CustomerId>
    </cus:GetCustomerRequest>
  </soap:Body>
</soap:Envelope>'

MockHub will return a valid SOAP XML response that matches the output message defined in your WSDL. The response comes back instantly from a real public URL — no local servers to manage.

For a CreateOrder operation, it might look like this:

curl -X POST https://mockhub.ovh/mock/example/order-service \
  -H "Content-Type: text/xml; charset=utf-8" \
  -H "SOAPAction: CreateOrder" \
  -d '<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:ord="http://example.com/orders">
  <soap:Header/>
  <soap:Body>
    <ord:CreateOrderRequest>
      <ord:ProductId>SKU-9981</ord:ProductId>
      <ord:Quantity>2</ord:Quantity>
    </ord:CreateOrderRequest>
  </soap:Body>
</soap:Envelope>'

The mock service responds with the XML structure your client code expects, so you can develop and test your integration without waiting for the real service.

---

Step 3: Customize Responses and Use Dynamic Variables

Out of the box, MockHub generates default responses based on your WSDL. But real-world testing often requires more control. You can edit any generated endpoint's response body directly from the MockHub dashboard.

One of the most powerful features is dynamic variables. Instead of hardcoding values, you can use placeholders that generate random data on every request. This makes your mock feel more like a real service — every call returns different, realistic data.

Here's an example of a customized SOAP response body using dynamic variables:

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:cus="http://example.com/customer">
  <soap:Body>
    <cus:GetCustomerResponse>
      <cus:CustomerId>{{uuid}}</cus:CustomerId>
      <cus:FullName>{{name}}</cus:FullName>
      <cus:Email>{{email}}</cus:Email>
      <cus:Phone>{{phone}}</cus:Phone>
      <cus:City>{{city}}</cus:City>
      <cus:Country>{{country}}</cus:Country>
      <cus:AccountCreated>{{isodate}}</cus:AccountCreated>
      <cus:CreditScore>{{integer}}</cus:CreditScore>
    </cus:GetCustomerResponse>
  </soap:Body>
</soap:Envelope>

Every time you call this endpoint, you'll get a different customer with a unique UUID, name, email, and so on. MockHub supports a wide range of variables including {{uuid}}, {{name}}, {{email}}, {{phone}}, {{city}}, {{country}}, {{isodate}}, {{integer}}, {{float}}, {{company}}, {{iban}}, and many more. You can find the full list in the MockHub documentation.

If you'd rather not write the response XML by hand, use the AI Body Generator — click "Generate with AI" in the endpoint editor and describe what you want in plain English. For example: "a SOAP response with customer name, email, account balance, and last login date" — and it generates the XML for you.

---

Step 4: Simulate Errors with Scenarios

Testing the happy path is easy. The hard part is testing what happens when things go wrong. Does your application handle a SOAP fault gracefully? What about a timeout?

MockHub's scenarios feature lets you define multiple responses for a single endpoint and switch between them programmatically. Here's a practical workflow:

1. Open your SOAP endpoint in the MockHub dashboard
2. Add a scenario called soap_fault — click "Add Scenario," then configure it with the response body set to a SOAP fault:

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <soap:Fault>
      <faultcode>soap:Server</faultcode>
      <faultstring>Customer not found</faultstring>
      <detail>
        <errorCode>ERR_404</errorCode>
        <message>No customer exists with the provided ID</message>
      </detail>
    </soap:Fault>
  </soap:Body>
</soap:Envelope>

Set the status code to 500 and save.

1. Switch to the error scenario programmatically before running your test:

curl -X POST https://mockhub.ovh/mock/example/customer-service/scenario/soap_fault

Now every call to that endpoint returns the SOAP fault. Run your test, verify your error handling works, then switch back to the success scenario.

You can also use the response delay feature to simulate a slow service. Set a delay of, say, 5000ms on a scenario to test how your application handles timeouts — without modifying any code on the mock side.

For more details, check the scenario setup guide and the scenario switching documentation.

---

Real-World Use Cases for SOAP Mocking

Here's where SOAP mocking with WSDL uploads really shines:

• Banking & finance integrations: Payment gateways, SWIFT messaging, and account verification services are almost always SOAP-based. Mock them during development to avoid using sandbox environments with rate limits.

• Healthcare & insurance: HL7/SOAP services for claims processing, eligibility checks, and patient data exchange. Mock these to develop and test without needing access to production-like environments.

• Government & legacy systems: Tax filing, customs declarations, and regulatory reporting APIs that haven't migrated to REST. Upload the WSDL, get a mock, and build your integration in parallel.

• CI/CD pipelines: Point your integration tests at MockHub endpoints instead of real services. Tests run faster, don't break when external services are down, and give you full control over response data.

MockHub also provides call logs and statistics for every endpoint, so you can verify that your application is sending correctly formatted SOAP envelopes. Check the dashboard to inspect the timestamp, headers, and full request body of every call — invaluable for debugging XML namespace issues or malformed envelopes.

---

Get Started

You can go from a WSDL file to a live mock SOAP service in under five minutes:

1. Register for free — no credit card required
2. Upload your WSDL — MockHub generates all the endpoints
3. Point your application at the mock URL and start building

The free plan gives you up to 5 mock APIs and 40 calls per month. If you need more (up to 100 APIs and 15,000 calls), check out the Premium plan.

SOAP integrations don't have to slow down your development cycle. Mock the service, build your client, test your error handling, and swap in the real endpoint when it's ready. Your future self — the one who isn't debugging XML at 11 PM — will thank you.

---

Have questions about mocking SOAP APIs or running into issues with a specific WSDL? Drop a comment below — happy to help.