DEV Community: Alfonso Rianna

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

Alfonso Rianna — Thu, 02 Apr 2026 09:21:44 +0000

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:

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.
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.
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:

Click on the SOAP mock generator page
Upload your WSDL file (or paste its contents)
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:

Open your SOAP endpoint in the MockHub dashboard
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.

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:

Register for free — no credit card required
Upload your WSDL — MockHub generates all the endpoints
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.

Mock API vs Real API: When to Use Each in Your Development Workflow

Alfonso Rianna — Thu, 26 Mar 2026 09:21:03 +0000

Mock API vs Real API: When to Use Each in Your Development Workflow

Every developer has been there. You're building a frontend feature, you're in the zone, and then you hit a wall — the backend endpoint you need doesn't exist yet. You could wait. You could bug the backend team. Or you could spin up a mock API and keep shipping.

But mock APIs aren't just a stopgap. Used strategically, they're a powerful part of a mature development workflow. The real question isn't mock or real — it's when to use each.

This article breaks down the practical tradeoffs between mock APIs and real APIs across development, testing, and CI/CD. We'll look at real examples, actual code, and a clear decision framework you can apply to your next project.

What's the Actual Difference?

Let's get precise before we go further.

A real API is a live service connected to real business logic, a real database, and real infrastructure. When you call GET /users, it queries a database and returns actual data. It can be slow, it can fail, and it can change without warning.

A mock API is a simulated endpoint that returns predefined or dynamically generated responses. It behaves like a real API from the consumer's perspective — same URL structure, same HTTP methods, same JSON responses — but there's no business logic behind it. It's a contract, not an implementation.

Here's a simple example. Say your team has agreed on this response shape for a user endpoint:

{
  "id": "550e8400-e29b-41d4-a716-446655440000",
  "name": "Jane Cooper",
  "email": "jane@example.com",
  "created_at": "2025-01-15T10:30:00Z"
}

With a tool like MockHub, you can create that endpoint in under a minute — complete with dynamic data that changes on every request using template variables like {{uuid}}, {{name}}, and {{email}}. No code. No server. Just a live URL.

When Mock APIs Win: Development & Prototyping

Use mock APIs when the backend doesn't exist yet — or when you don't want to depend on it.

This is the most common scenario. The frontend team and backend team have agreed on an API contract (ideally via an OpenAPI spec), but the backend implementation is weeks away. Without mocks, the frontend team is blocked.

Here's how fast you can unblock yourself. Create a mock endpoint on MockHub with this response body:

[
  {
    "id": "{{uuid}}",
    "name": "{{name}}",
    "email": "{{email}}",
    "role": "{{jobtitle}}",
    "active": {{boolean}}
  },
  {
    "id": "{{uuid}}",
    "name": "{{name}}",
    "email": "{{email}}",
    "role": "{{jobtitle}}",
    "active": {{boolean}}
  }
]

Every call returns different realistic data thanks to those dynamic variables. Now test it:

curl https://mockhub.ovh/mock/example/users

You'll get back something like:

[
  {
    "id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
    "name": "Sarah Mitchell",
    "email": "user2947@example.com",
    "role": "Product Manager",
    "active": true
  },
  {
    "id": "f9e8d7c6-b5a4-3210-fedc-ba0987654321",
    "name": "Marcus Chen",
    "email": "user8831@example.com",
    "role": "DevOps Engineer",
    "active": false
  }
]

Now your React component, your Vue page, your mobile app — whatever the consumer is — can develop against a real HTTP endpoint with realistic data. No hardcoded JSON files. No if (process.env.NODE_ENV === 'development') hacks.

Other scenarios where mocks win during development:

Third-party APIs with rate limits. Stripe, Twilio, GitHub — you don't want to burn API calls (or money) while iterating on UI logic.
Offline development. MockHub endpoints are cloud-hosted and always available, but they don't require you to run a local backend stack.
Demos and prototypes. Need to show a stakeholder a working UI tomorrow? Mock the API and focus on the experience.

When Real APIs Win: Integration & Pre-Production

Use real APIs when you need to validate actual behavior, not just the contract.

Mock APIs tell you: "My code handles this response shape correctly."

Real APIs tell you: "The system actually works end-to-end."

Both are valuable. They answer different questions.

Switch to real APIs when:

You're testing authentication flows. OAuth tokens, session handling, refresh logic — these need the real auth server.
You're validating data transformations. If the backend applies business rules (tax calculations, permission filtering, pagination), mocks won't catch logic bugs.
You're doing performance testing. Response time, payload size, connection pooling — these only matter against real infrastructure.
You're in staging or pre-production. This is where integration testing lives. Everything should be real (or as close to real as possible).

The key insight: mock APIs validate your code; real APIs validate the system. You need both.

The Testing Sweet Spot: Using Both Together

Here's where things get interesting. The best testing strategies don't choose between mock and real — they layer them.

Unit & Component Tests → Mock APIs

Your unit tests and component tests should be fast, deterministic, and independent of external services. This is where mock APIs shine.

Here's a JavaScript example using fetch against a MockHub endpoint in a test helper:

// test/helpers/api.js
const MOCK_BASE_URL = 'https://mockhub.ovh/mock/example';

async function fetchUsers() {
  const response = await fetch(`${MOCK_BASE_URL}/users`);
  if (!response.ok) {
    throw new Error(`API error: ${response.status}`);
  }
  return response.json();
}

// In your test
test('renders user list correctly', async () => {
  const users = await fetchUsers();
  expect(users).toBeInstanceOf(Array);
  expect(users[0]).toHaveProperty('id');
  expect(users[0]).toHaveProperty('name');
  expect(users[0]).toHaveProperty('email');
});

Because MockHub endpoints return dynamic but structurally consistent data, your tests validate the contract — which is exactly what component tests should do.

Simulating Failures with Scenarios

Good tests don't just cover the happy path. You need to verify how your app handles a 500 error, a 401 unauthorized response, or a slow network.

MockHub's scenarios feature lets you configure multiple responses for a single endpoint. Create a scenario called server_error with status code 500 and body {"error": "Internal Server Error"}, then switch to it programmatically:

# Switch the endpoint to return a 500 error
curl -X POST https://mockhub.ovh/mock/example/users/scenario/server_error

# Now this call returns a 500
curl https://mockhub.ovh/mock/example/users

This is incredibly powerful for test-driven development. Write the test for error handling first, point it at the error scenario, then implement the error handling in your code.

Integration & E2E Tests → Real APIs

Once your unit tests pass against mocks, run your integration suite against the real (or staging) API. This catches the issues mocks can't: serialization mismatches, missing headers, unexpected nulls in real data, auth edge cases.

The layered approach:

Test Type	API Type	What It Validates
Unit / Component	Mock API	Response handling, UI rendering, error states
Integration	Real API (staging)	End-to-end data flow, auth, business logic
E2E / Smoke	Real API (staging)	Full user workflows, cross-service interactions

Mock APIs in CI/CD Pipelines

This is where mock APIs deliver outsized value.

CI/CD pipelines need to be fast and reliable. Real API dependencies introduce flakiness — the staging server is down, the database got wiped, the third-party API is rate-limiting your build agent. One flaky dependency and your entire pipeline turns red.

Mock APIs eliminate that class of failures entirely. Your pipeline runs against deterministic, always-available endpoints.

A practical CI/CD strategy:

Build stage: Run unit tests against MockHub endpoints. Fast, no external dependencies beyond MockHub's uptime.
Integration stage: Run against a real staging environment. Slower, but validates actual behavior.
Deploy stage: Run smoke tests against production mock endpoints to verify your API client code still matches the expected contract.

If you have an OpenAPI spec, you can import it directly into MockHub via the OpenAPI import tool and auto-generate every endpoint. When the spec changes, re-import and your mocks stay in sync with the contract.

A Decision Framework You Can Actually Use

When someone on your team asks "should I use a mock or the real API?", run through this checklist:

Use a mock API when:

✅ The real API doesn't exist yet
✅ You're writing unit or component tests
✅ You need to simulate specific error codes or slow responses
✅ You're running tests in CI and need reliability
✅ You're working with rate-limited or paid third-party APIs
✅ You're building a demo or prototype

Use the real API when:

✅ You're testing authentication and authorization
✅ You need to validate business logic and data transformations
✅ You're doing performance or load testing
✅ You're in the integration or E2E testing phase
✅ You're debugging a production issue

Use both when:

✅ You want a robust, layered testing strategy (you should)

Get Started

If you don't have a mock API workflow yet, the fastest way to start is MockHub. The free plan gives you 5 mock APIs with 40 calls per month — enough to try out everything in this article.

Here's your 5-minute challenge:

Register for free (no credit card)
Create a GET /users endpoint with dynamic variables like {{uuid}}, {{name}}, and {{email}}
Call it with curl or fetch
Add a scenario for a 500 error
Write one test for the happy path and one for the error path

You'll never go back to waiting on the backend team again.

Wrapping Up

Mock APIs and real APIs aren't competing tools — they're complementary strategies. Mocks give you speed, independence, and determinism during development and unit testing. Real APIs give you confidence that the full system works during integration and pre-production.

The teams that ship fastest use both, deliberately, at the right time. Now you have the framework to do the same.

Have a mock API workflow tip I didn't cover? Drop it in the comments — I'd love to hear how your team handles this.

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

Alfonso Rianna — Tue, 24 Mar 2026 10:25:44 +0000

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

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.