SOAP (Simple Object Access Protocol) is a messaging protocol that lets applications exchange structured data across different systems, platforms and programming languages. Every message is formatted in XML and follows a strict, published contract, which is why SOAP is still the backbone of integration in insurance, banking, utilities, telecommunications and healthcare — industries where a malformed message is a compliance problem, not just a bug.
This guide covers what a SOAP API is, how a SOAP message is structured, what SOAP does well, where it costs you, and how to decide between SOAP and REST for a given interface. If you are connecting a modern application to a decades-old core system, you will almost certainly meet SOAP on the way.
What is a SOAP API?
A SOAP API is an interface built on the SOAP protocol. It lets applications and systems talk to each other over a network by exchanging structured XML messages, and it makes services and functions available to any client that can read that contract. Because the format is defined independently of the runtime, a Java service can be consumed by a .NET client, a mainframe transaction can be triggered from a web application, and neither side needs to know anything about the other’s technology stack.
SOAP also supports remote procedure calls, meaning a client can invoke a function that lives in a completely different address space and receive a typed result back. That capability is one reason SOAP became the default in service-oriented architectures (SOA) and in distributed enterprise landscapes where dozens of systems need a shared, predictable way to call each other.
The name is a historical artefact: SOAP originally stood for Simple Object Access Protocol, but the acronym was formally dropped in SOAP 1.2. Today it is simply SOAP.
What are the components of a SOAP message?
Every SOAP message is an XML document, which is what makes structured data transfer platform- and language-independent. The message is built from three elements — plus one special case.
SOAP envelope
The SOAP envelope is the outer wrapper. It marks the beginning and the end of the message and contains everything else. If a message has no envelope, it is not a SOAP message.
SOAP header
The header is optional and carries metadata rather than payload: authentication credentials, routing instructions, transaction identifiers, digital signatures. Anything the receiving system or an intermediate node needs in order to process the message correctly belongs here, not in the body.
SOAP body
The body carries the actual data being exchanged between applications, including the instructions for any remote procedure call. This is the part that maps to your business operation — the policy record, the meter reading, the payment instruction.
SOAP fault
The body can also contain a fault element. When something goes wrong during processing, the receiving application returns a structured fault instead of the expected result, with a code and a human-readable reason. Standardised error handling is one of SOAP’s genuine strengths: your integration layer does not have to guess what a failure means from an HTTP status code alone.
What does a typical SOAP message flow look like?
A SOAP message is exchanged between a client and a server application. There is always a SOAP sender and a SOAP receiver, and the receiver interprets and validates whatever the sender submitted. Between the two, the message can pass through one or more intermediate SOAP nodes. Each node must react to the message — it may process it, enrich it, or raise a fault.
Messages are usually transported over HTTP, but SOAP is deliberately transport-agnostic. SMTP (Simple Mail Transfer Protocol) and JMS (Java Message Service) are equally valid carriers, which matters when you need guaranteed, asynchronous delivery rather than a synchronous request/response over the web.
SOAP and WSDL: the contract that makes it work
SOAP web services are normally described using WSDL (Web Services Description Language). A WSDL file is a machine-readable specification of what the service offers: which operations exist, what each one expects as input, what it returns, and where it can be reached.
The practical consequence is that development teams do not have to negotiate the interface in a meeting. A client stub can be generated directly from the WSDL, and if the provider changes the contract, the consumer’s build breaks immediately rather than silently sending malformed requests into production. In large organisations with separate teams on either side of an interface, this formality is a feature, not overhead.
What are the benefits of SOAP for enterprises?
Built-in security. WS-Security defines encryption and digital signatures at the message level rather than only at the transport level. A signed SOAP message stays verifiable after it leaves the TLS tunnel — through an intermediary, into a queue, and out again. For sensitive data crossing organisational boundaries, that end-to-end guarantee is hard to replicate.
Reliable messaging. WS-ReliableMessaging and related standards detect transmission errors and guarantee message integrity and delivery semantics. In business-critical processes — a payment, a policy change, a grid switching command — knowing that a message arrived exactly once is worth the extra bytes.
Transport interoperability. Because SOAP sits on top of the TCP/IP stack rather than binding itself to one protocol, it works over HTTP/HTTPS, FTP, SMTP and message queues. It integrates technologies seamlessly regardless of platform, operating system or programming language.
Complex data structures. XML handles deeply nested, strongly typed payloads with schema validation. Where a REST endpoint would need custom validation logic, an XSD does the work before your business code ever runs.
A formal contract. WSDL makes collaboration between separate development teams straightforward, and it makes the interface auditable — which regulators in finance, insurance and healthcare tend to appreciate.
An international standard. SOAP is a W3C recommendation. Stability and consistency over decades is precisely why so many core systems still speak it.
What are the challenges of using SOAP?
SOAP is not the right answer everywhere, and the reasons are worth being honest about.
Verbosity and complexity. The XML structure makes SOAP messages considerably heavier than the JSON payloads used by REST. Development, debugging and simply reading a message take longer, and interoperability with certain platforms can require additional integration effort.
Network and processing overhead. Additional security and header information means larger messages and longer processing times than a comparable REST call. On a high-volume, latency-sensitive public API, that difference is measurable.
Scope. SOAP defines message exchange. It is not a complete object architecture, and it does not solve service discovery, versioning strategy or client-side caching for you.
Developer availability. New services are overwhelmingly built with REST, so the pool of engineers who are fluent in WSDL, XSD and WS-* is shrinking. That is a staffing risk on long-lived SOAP estates, not a technical flaw.
For most new web services the trend points towards lighter formats such as those used by REST. Whether SOAP is the right choice depends on your existing infrastructure, your compliance requirements and the resources available to you.
SOAP vs REST: which one should you use?
SOAP and REST are both approaches to implementing web services and enabling communication between distributed applications. They differ in communication style, data format and how they use the underlying transport. SOAP is a protocol with a strict specification; REST is an architectural style built on existing web standards.
| Criterion | SOAP | REST |
|---|---|---|
| Type | Protocol with a formal specification | Architectural style |
| Data format | XML only | JSON, XML, plain text, others |
| Transport | HTTP, SMTP, JMS, FTP | HTTP/HTTPS |
| Contract | WSDL, machine-readable and enforced | OpenAPI, conventional rather than enforced |
| Security | WS-Security, message-level | HTTPS, OAuth 2.0, transport-level |
| State | Stateful operations supported | Stateless by design |
| Error handling | Standardised SOAP fault | HTTP status codes plus custom payloads |
| Payload size | Larger — envelope and headers add overhead | Smaller — lightweight JSON |
| Best suited to | SOA, regulated industries, legacy core systems, guaranteed delivery | Web and mobile applications, microservices, public APIs |
In practice the choice depends on the requirements of the specific interface, not on a company-wide preference. REST is usually the better fit for web applications and public APIs; SOAP remains the stronger option for complex communication architectures such as service-oriented architecture, and wherever a legacy system already exposes a WSDL. Most enterprise landscapes end up running both — which is exactly the problem an integration platform is designed to solve.
For the other side of this comparison, see our guide to REST APIs and RESTful web services.
Which industries still rely on SOAP?
SOAP is deployed across sectors where regulated, high-value transactions dominate. Insurance carriers use it for policy and claims exchange, banks for payment and account interfaces, utilities and energy providers for metering and grid communication, telecommunications operators for provisioning and billing, and healthcare organisations for patient and billing data. In all of these, the installed base of SOAP interfaces is measured in decades, not years.
The future of SOAP: what should enterprises expect?
New API development is moving towards REST, but SOAP retains a clear justification in specific systems and applications. The realistic expectation is that existing SOAP architectures will need long-term maintenance, particularly where they front older technologies that are not going to be replaced any time soon.
SOAP also continues to open up new options. Exposing SOAP-based services in the cloud gives organisations access to additional functions and data, and cloud infrastructure lets them scale resources flexibly: when demand for a SOAP service rises, the platform can provide additional capacity for load balancing. The more common pattern, though, is a facade — a modern REST or event-driven interface in front of a stable SOAP core, so new applications never have to speak WSDL directly.
Connecting SOAP services with X4 BPMS
Most integration projects do not fail on the protocol. They fail on the number of protocols. A single process might need to read from a SOAP web service, write to a REST endpoint, pick up a file over SFTP and publish an event to a queue — and someone has to hold all of that together.
The X4 BPMS low-code platform ships with more than 200 prebuilt adapters, including SOAP and REST clients and servers, so connecting a legacy web service does not require custom code. Its integrated enterprise service bus handles routing, transformation and message flow between systems, and modelled BPMN 2.0 processes let you orchestrate what happens across them: call the SOAP service, transform the XML, enrich it from a second system, and hand the result to the process that needs it.
API management matters here because it is what turns individual interfaces into a governed capability. A central platform makes systems and data accessible to internal and external developers, which accelerates the development of new digital products and services, keeps processes agile as the market changes, and simplifies collaboration between internal teams and external partners. Read more about seamless integration or about the choice between ESB, middleware and microservices.
Are you in the middle of a digital transformation? We support you through design and delivery, from training through to dedicated development teams — see our consulting services or explore how business process automation works in practice.
As Chief Technology Officer, Wolfgang Wiesner has been driving the technological advancement of SoftProject since May 2025. His focus is on future-proof architectures, technological excellence, and the successful implementation of innovative IT solutions.
FAQs
What is a SOAP API?
A SOAP API is an interface based on the SOAP protocol. It allows applications to exchange structured XML messages over a network, so that services and functions from one system can be used by another regardless of platform or programming language.
What does SOAP stand for?
SOAP originally stood for Simple Object Access Protocol. The acronym was officially dropped with SOAP 1.2, so the name is now used on its own.
What is the difference between a SOAP API and a REST API?
SOAP is a protocol with a strict specification that uses XML exclusively and can run over several transports. REST is an architectural style that uses HTTP and typically exchanges JSON. SOAP offers message-level security and a formal WSDL contract; REST is lighter, faster to develop against and better suited to web and mobile applications.
Is SOAP still used in 2026?
Yes. New public APIs are almost always REST, but SOAP remains widely deployed in insurance, banking, utilities, telecommunications and healthcare, where existing core systems expose SOAP interfaces and message-level security and guaranteed delivery are required.
What is a SOAP envelope?
The SOAP envelope is the outermost XML element of a SOAP message. It defines where the message starts and ends and contains the optional header and the mandatory body.
Can SOAP and REST run side by side?
Yes, and in most enterprise landscapes they do. An integration platform such as X4 BPMS can consume a SOAP web service and expose the same business capability as a REST endpoint, so new applications never need to work with WSDL directly.
