SoapUI is an open-source tool for testing web services and APIs. It started in 2005 as a way to test SOAP services, hence the name, and it later grew to handle REST, GraphQL, JMS, and JDBC as well. For two decades it has been a fixture in enterprise QA teams, especially those maintaining older SOAP-based integrations that newer tools tend to ignore.
If you have only worked with JSON REST APIs and a modern client, SoapUI can feel like a relic. But it is still one of the few tools that handles WSDL-driven SOAP testing properly, and it remains relevant wherever banks, insurers, government systems, and telecom platforms run XML web services. This guide explains what SoapUI does, the features that matter, when it is the right choice, and the limitations that push many teams toward alternatives.
What SoapUI actually does
SoapUI is a desktop application that lets you create, send, and validate API requests without writing application code. You point it at a service definition, build test requests against it, add assertions, and run those requests as suites.
Its defining trick is WSDL import. A WSDL (Web Services Description Language) file is an XML document that fully describes a SOAP service: its operations, message formats, and data types. Feed SoapUI a WSDL URL and it generates skeleton requests for every operation, pre-filled with the correct XML envelope structure. You fill in the values and send. That automatic generation is why SoapUI stuck around for SOAP work; hand-writing a SOAP envelope is tedious and error-prone.
On the REST side, SoapUI imports OpenAPI and WADL definitions and lets you build requests with methods, parameters, headers, and bodies, much like any other API client. It supports both styles in one project, which is useful for teams mid-migration from SOAP to REST.
SoapUI ships in two editions. The open-source version covers core functional testing and is free. ReadyAPI is the commercial edition from SmartBear; it adds load testing, security scanning, data-driven testing from external sources, and a more polished interface. When people say “SoapUI” they usually mean the free open-source tool, and that is the focus here.
Key features
SoapUI’s feature set is built around a clear hierarchy: projects contain test suites, test suites contain test cases, and test cases contain test steps.
- Projects. A project holds all the requests, suites, and configuration for one service or one related group of services. It is the top-level container you save and share with the team.
- Functional test suites. Inside a project you build test cases made of ordered steps. A step can be a request, an assertion, a property transfer, a delay, or a script. Steps run in sequence, so you can log in, capture a token, and reuse it in later requests.
- Assertions. SoapUI offers a wide range of built-in assertions: status code checks, XPath and XQuery matches against XML responses, JSONPath checks against JSON, schema compliance, SLA response-time limits, and content matching. These let you validate a response without writing code. Our guide to API assertions explains the patterns that apply here.
- Property transfer. This step copies a value from one response into a later request. It is how you chain calls: extract a session ID from a login response and inject it into the next call. It is the SoapUI equivalent of variable extraction in other tools.
- Groovy scripting. When built-in steps are not enough, SoapUI runs Groovy scripts. You can generate dynamic data, transform payloads, run custom assertions, or call external systems. This is the escape hatch that makes SoapUI flexible for complex enterprise scenarios.
- Mock services. SoapUI can stand up a mock of a SOAP or REST service from its definition, so you can test a client before the real backend exists. If mocking is central to your workflow, compare options in our API mocking use cases article.
Together these features make SoapUI a complete functional testing environment for XML-heavy services, which is exactly the niche it was built for.
A typical SoapUI workflow
Walking through a basic SoapUI session makes the hierarchy concrete. Here is how a tester usually approaches a new service.
- Create a project from a definition. You start SoapUI, create a new project, and paste in a WSDL URL for a SOAP service or an OpenAPI file for a REST service. SoapUI parses it and generates a tree of operations or endpoints.
- Send an exploratory request. You open one of the generated requests, fill in sample values, and click submit. SoapUI shows the raw response, formatted as XML or JSON, so you can confirm the service responds as expected.
- Build a test suite. Once you understand the service, you create a test suite, add test cases, and add test steps inside them. A login step captures a token, a property transfer step moves that token forward, and subsequent request steps use it.
- Add assertions. On each request step you attach assertions: a status code check, an XPath match on a specific element, an SLA limit on response time. These turn a request into a real test that passes or fails.
- Run and review. You run the test case or the whole suite. SoapUI shows a pass or fail result per step and per assertion, with the response data available for any failure you need to investigate.
This cycle, definition to exploration to suite to assertions to run, is the same whether you test SOAP or REST. The structure is what gives SoapUI its power and also what makes it feel heavy for small jobs.
SoapUI compared to other tools
It helps to place SoapUI against the tools testers reach for today. The table below sketches the broad strokes.
| Aspect | SoapUI | Modern REST clients |
|---|---|---|
| SOAP and WSDL support | Strong, first-class | Weak or absent |
| XML assertions (XPath, XQuery) | Extensive | Limited |
| REST and OpenAPI support | Adequate | First-class |
| Interface | Dense, dated | Streamlined, modern |
| Learning curve | Steep | Gentler |
| Load testing in free edition | Not included | Varies |
The summary the table points to is simple. SoapUI wins decisively on SOAP and XML, and modern clients win on REST workflow and approachability. Your stack decides which column matters more.
When SoapUI is the right choice
SoapUI is a strong pick in specific situations. Use it when you maintain SOAP services and need real WSDL support, because few modern tools handle SOAP envelopes and WS-Security as cleanly. Use it when you work in an enterprise that already standardized on SoapUI or ReadyAPI, since switching costs and existing test assets favor continuity. Use it when you need XPath or XQuery assertions against deeply nested XML, an area where SoapUI is genuinely strong.
It also fits teams that want a free, no-code functional testing tool and can absorb the learning curve. If your services are SOAP-first, SoapUI will likely be faster to set up than forcing a REST-oriented tool to handle XML. For a broader survey of testing approaches, see our overview of what automated testing is.
Where SoapUI falls short
SoapUI carries the weight of its age, and the limitations are real.
The learning curve is steep. The project-suite-case-step hierarchy is powerful but unintuitive, and the interface exposes a lot of options at once. New users routinely feel lost. Building anything beyond a basic request often means dropping into Groovy, which adds a scripting requirement to a tool marketed as no-code.
Resource use is heavy. SoapUI is a Java desktop application, and large projects with many suites can make it sluggish. On modest hardware, opening a big project and running suites tests your patience.
The open-source edition does not do load testing. Performance and concurrency testing live in the paid ReadyAPI product. If you need both functional and load coverage, you either pay or add a second tool. Our guide to software performance testing tools covers the alternatives.
CI/CD integration is workable but dated. SoapUI can run from the command line and there is a Maven plugin, but the experience feels bolted on next to tools designed for pipelines from the start. The interface itself reflects an older era of desktop software and has not kept pace with modern API clients.
Finally, SoapUI is REST-capable but SOAP-shaped. If your entire stack is JSON REST APIs, you will likely find a modern client faster and more pleasant. SoapUI earns its place where SOAP and XML are still in play.
A modern alternative: Apidog
For teams whose APIs are primarily REST, GraphQL, or built around OpenAPI, Apidog offers a more current take on the same workflow. It combines API design, debugging, automated functional testing, and mock servers in one application. You design a schema, send requests, add visual assertions without scripting, and chain steps into automated test scenarios, all in an interface built for modern API work rather than retrofitted onto a twenty-year-old foundation.
Apidog also includes performance testing in the same tool, so you do not need a separate paid product for load coverage. It supports CI/CD through a command-line runner and integrates cleanly with pipelines. You can download Apidog and use its core testing features for free. If you still need SOAP-specific testing, our online SOAP API tester guide covers options for that case.
The honest summary: SoapUI remains the practical choice for SOAP-heavy enterprise testing, and it is free and capable in that niche. For greenfield REST projects, a modern platform will usually serve you better.
Frequently asked questions
Is SoapUI free?
The open-source edition of SoapUI is free and covers functional testing for SOAP and REST APIs. ReadyAPI, the commercial edition from SmartBear, is a paid product that adds load testing, security scanning, advanced data-driven testing, and a refined interface. Most references to “SoapUI” mean the free open-source tool.
Does SoapUI only test SOAP APIs?
No. Despite the name, SoapUI tests REST, GraphQL, JMS, and JDBC in addition to SOAP. It imports OpenAPI and WADL definitions for REST services. That said, its WSDL support and XML assertion capabilities are its strongest features, so it is most compelling for teams with SOAP services to maintain.
Can SoapUI run in a CI/CD pipeline?
Yes. SoapUI can run test suites from the command line, and there is a Maven plugin for build integration. The experience works but feels less polished than tools designed for pipelines from the ground up. For heavy CI use, evaluate how comfortable the command-line runner is for your workflow.
What is the difference between SoapUI and Postman?
SoapUI has deeper SOAP and WSDL support and stronger XML assertions, and it is built around a structured test suite hierarchy. Postman is REST-first, has a friendlier interface, and a larger ecosystem. Teams maintaining SOAP services often prefer SoapUI; teams building JSON REST APIs usually prefer Postman or a modern alternative.
Do I need to know Groovy to use SoapUI?
Not for basic requests and built-in assertions. But anything dynamic, such as generating test data, transforming payloads, or writing custom validation logic, typically requires Groovy scripts. Plan to learn some Groovy if your testing goes beyond simple request-and-assert scenarios.
Is SoapUI still relevant in 2026?
Yes, in its niche. SOAP services have not disappeared; they remain common in banking, insurance, government, healthcare, and telecom systems that were built years ago and still run. For testing those services, SoapUI’s WSDL support is hard to match. For new REST and GraphQL projects, most teams choose a modern tool. SoapUI is relevant where SOAP is relevant.
What is the difference between SoapUI and ReadyAPI?
SoapUI is the free, open-source functional testing tool. ReadyAPI is the commercial product from SmartBear that builds on the same foundation and adds load testing, security testing, advanced data-driven testing, and a more refined interface. If you need performance testing or security scanning without adding a second tool, ReadyAPI is the paid path; otherwise the free SoapUI covers functional testing.