SoapUI Mock Service: Setup Guide and Modern Alternative

TL;DR

SoapUI mock services simulate SOAP or REST endpoints locally, but they run inside a Java process, require manual dispatch configuration, and are hard to share across a team without a shared machine. Apidog Smart Mock generates mock responses from your API schema, runs in the cloud, and gives your team a shared mock URL.

Try Apidog today

Apidog is a free, all-in-one API development platform with built-in Smart Mock for creating instant mock endpoints from API definitions without running a local Java process.

Introduction

Mock services help you test client code before the real API is ready. They are also useful for testing error states, slow responses, and edge cases without changing production or staging systems.

SoapUI’s mock service feature works by running a local HTTP server that returns configured responses. The tradeoff is operational friction:

• The mock stops when SoapUI closes.
• Teammates cannot access localhost without extra networking setup.
• Dispatch rules often require Groovy scripting.
• HTTPS and stateful workflows need additional configuration.

This guide shows how SoapUI mock services work, how to configure them, common issues teams hit, and how Apidog Smart Mock compares.

How SoapUI mock services work

SoapUI creates mock services from SOAP or REST interfaces in a project.

A SoapUI mock service:

1. Listens on a local port, for example:

   http://localhost:8088/MockService

1. Receives incoming requests.
2. Matches the request to a mock response using dispatch logic.
3. Returns the configured response.

For SOAP services, SoapUI can generate mock responses from a WSDL. It creates stub responses for each operation, which is useful when the real service is not available yet.

Set up a SoapUI mock service

SOAP interface

1. Open your SoapUI project.
2. Right-click a SOAP interface in the project tree.
3. Select Generate MockService.
4. Configure the mock service:
   • Service name: OrderService Mock
   • Port: 8088
   • Path: /orders
5. Click OK.
6. Expand the generated MockService node.
7. Open a MockOperation.
8. Edit the SOAP response XML.
9. Click the green Play button to start the local mock server.

Your mock is now available at:

http://localhost:8088/orders

Point your client application to that URL.

REST interface

1. Right-click a REST interface or resource.
2. Select Add to MockService or Generate MockService.
3. Configure the port and path.
4. For each resource and method, configure:
   • Response body
   • HTTP status code
   • Optional delay
5. Start the mock service.

Configure dispatch in SoapUI

By default, SoapUI returns the first matching mock response. To return different responses for different inputs, configure dispatch behavior.

Common dispatch options:

• SEQUENCE: returns responses in order across successive calls.
• SCRIPT: uses a Groovy script to inspect the request and select a response.

Example Groovy dispatch script:

def request = mockRequest.getRequestContent()

if (request.contains("orderId>12345")) {
  return "OrderFoundResponse"
} else {
  return "OrderNotFoundResponse"
}

To use this pattern:

1. Create multiple named mock responses:
   • OrderFoundResponse
   • OrderNotFoundResponse
2. Set the dispatch type to SCRIPT.
3. Add Groovy logic that returns the response name.

This works, but string matching against raw SOAP XML can become fragile when namespaces or prefixes change.

Common SoapUI mock service problems

1. The mock stops when SoapUI closes

SoapUI mock services run inside the SoapUI JVM process. When SoapUI closes, the mock stops.

Workarounds:

• Keep SoapUI open on a dedicated machine.
• Run the mock from the command line.
• Host the mock on a shared VM or server.

Example command-line runner:

mockservicerunner.sh -p 8088 -s "OrderService Mock" project.xml

On Windows:

mockservicerunner.bat -p 8088 -s "OrderService Mock" project.xml

This avoids keeping the GUI open, but you still need Java and SoapUI installed on the machine running the mock.

2. Sharing the mock requires networking setup

A mock running on:

http://localhost:8088

is only available to the developer running it.

To share it, you need one of the following:

• A shared machine
• Firewall configuration
• VPN access
• Port forwarding
• A CI or server environment running the mock service

For distributed teams, this adds coordination overhead.

3. Dispatch scripts can break with complex XML

SOAP envelopes often include namespaces. The same logical value can be represented with different namespace prefixes.

For example:

<ns1:orderId>12345</ns1:orderId>

and:

<ord:orderId>12345</ord:orderId>

represent the same field, but simple string matching may fail.

A brittle script like this:

request.contains("<orderId>12345</orderId>")

can break when the client changes namespace prefixes.

A more reliable approach requires XML parsing with SoapUI Groovy utilities, which increases script complexity.

4. State does not persist by default

SoapUI mock services are stateless unless you add custom logic.

For example, if you want this workflow:

1. POST /orders creates an order.
2. GET /orders/{id} returns the created order.

You need Groovy logic to store state in a shared variable or project-level property. This is possible, but it can become brittle as workflows grow.

5. HTTPS setup is manual

To run a SoapUI mock service over HTTPS, you need to configure:

• A keystore
• SoapUI SSL settings
• Client trust configuration
• The correct certificate chain

For many teams, this is more setup than they want for a development mock.

Apidog Smart Mock: how it compares

Apidog Smart Mock starts from the API design rather than a local process.

When you define an API endpoint in Apidog with a method, path, request schema, and response schema, Apidog can generate a cloud mock endpoint.

Example mock URL:

https://{your-project}.mock.apidog.io/orders/{id}

The mock URL is:

• Always available without starting a local process
• Shareable with teammates
• Generated from the API schema
• Usable during frontend, backend, and QA workflows

Generate mock responses from an API schema

Apidog reads your response schema, such as an OpenAPI response definition or JSON Schema, and generates mock data from it.

For example, if your schema defines:

{
  "type": "object",
  "properties": {
    "orderId": {
      "type": "string",
      "format": "uuid"
    },
    "amount": {
      "type": "number",
      "minimum": 0,
      "maximum": 10000
    },
    "status": {
      "type": "string",
      "enum": ["pending", "paid", "cancelled"]
    }
  }
}

A mock response can return values that match the schema:

{
  "orderId": "6f9f0b4d-5b4f-4b9f-8e7a-0f4e3f1e7f91",
  "amount": 482.75,
  "status": "paid"
}

You can also configure custom mock rules for predictable test values.

For example:

{
  "orderId": "test-123",
  "amount": 99.99,
  "status": "pending"
}

This is useful when frontend tests or automated tests need stable values.

Mock SOAP endpoints in Apidog

Apidog Smart Mock is primarily designed for REST APIs with JSON responses.

For SOAP APIs, the setup is more manual:

1. Create a request in Apidog.
2. Configure the endpoint path and method.
3. Add a custom XML response body.
4. Return a SOAP envelope from the mock server.

Example SOAP response:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <GetOrderResponse>
      <orderId>12345</orderId>
      <status>paid</status>
    </GetOrderResponse>
  </soap:Body>
</soap:Envelope>

This does not provide SoapUI-style WSDL stub generation, but it works when you need a shared SOAP mock without running a local Java process.

Stateful mocking in Apidog

Apidog supports custom response scripts for dynamic mock behavior.

You can inspect the request and return different responses based on request content, similar to SoapUI dispatch scripts, but using JavaScript instead of Groovy.

This is useful for scenarios like:

• Returning different responses for different request bodies
• Simulating error cases
• Matching query parameters
• Testing create-read workflows
• Returning predictable responses for automated tests

SoapUI vs Apidog Smart Mock

Feature	SoapUI Mock	Apidog Smart Mock
Requires Java	Yes	No
Runs locally	Yes	No, cloud-based
Always on	Only with command-line runner or shared machine	Yes
Team accessible	Requires networking setup	Yes, via shared mock URL
WSDL auto-generation	Yes	No
REST schema-based mocking	No	Yes
Dynamic responses	Groovy dispatch scripts	JavaScript mock scripts
HTTPS support	Manual keystore setup	Built in
Stateful mocking	Via Groovy variables	Via JavaScript scripts
Free option	Yes	Yes

When to use SoapUI mock services

Use SoapUI mock services when:

• You need WSDL-based SOAP mock generation.
• You want auto-generated SOAP response stubs.
• Your team works offline or inside strict network controls.
• You already maintain SoapUI projects.
• Your mocks are mostly local and developer-specific.

SoapUI is still useful for SOAP-heavy workflows, especially when the WSDL is the source of truth.

When to use Apidog Smart Mock

Use Apidog Smart Mock when:

• You are mocking REST APIs.
• You want shared mock URLs without network setup.
• Your team defines API contracts before implementation.
• You want cloud-hosted mocks that stay running.
• You want schema-based mock data.
• You want to avoid installing and maintaining Java for mock services.

Apidog is especially useful for frontend and backend teams working in parallel from an API contract.

FAQ

Can I run SoapUI mock services without the GUI?

Yes. SoapUI includes command-line mock runners:

mockservicerunner.sh

and on Windows:

mockservicerunner.bat

Example:

mockservicerunner.sh -p 8088 -s "OrderService Mock" project.xml

You still need Java and SoapUI installed, but the GUI does not need to stay open.

Does Apidog support SOAP mock services?

Partially. You can configure custom SOAP XML responses in Apidog’s mock server, but Apidog does not generate SOAP stubs from a WSDL the way SoapUI does.

For teams with known SOAP request and response formats, manual SOAP mock setup can be enough.

Can SoapUI mock services simulate slow responses?

Yes. SoapUI mock responses support a delay value in milliseconds.

For example, you can configure a response delay to simulate a slow dependency:

Delay: 3000 ms

Apidog also supports response delay configuration for slow network simulation.

How many mock requests can Apidog handle?

Apidog’s cloud mock server is intended for typical development and testing workloads. For high-volume performance testing, use a dedicated mock or load-testing setup.

What if two developers need different mock responses for the same endpoint?

In SoapUI, each developer can run a local mock with their own configuration.

In Apidog, you can use approaches such as:

• Multiple environments
• Query parameters to select scenarios
• Request matching rules
• Mock expectations for specific request conditions

This lets teams share a base mock while still testing different cases.

Does Apidog require the full API schema first?

No. A response schema helps Apidog generate realistic mock data, but you can also create manual mock responses.

A minimal workflow is:

1. Define the endpoint path and method.
2. Add a custom response body.
3. Use the generated mock URL.

Conclusion

SoapUI mock services are functional and especially useful for WSDL-based SOAP workflows, but they are tied to a local Java process and require extra work for sharing, HTTPS, dispatching, and persistence.

For teams building REST APIs from shared contracts, Apidog Smart Mock removes much of that setup by generating cloud-hosted mock endpoints from API definitions and making them available through shared URLs.