SOAP
SOAP (Simple Object Access Protocol) is a standardized protocol that software systems use to exchange structured data in the form of XML messages. In an ERP context, SOAP serves as an interface through which an ERP system handles strictly defined requests and responses with third-party systems such as accounting, logistics or legacy business applications.
SOAP (Simple Object Access Protocol) is a standardized messaging protocol that two software systems use to exchange structured data – strictly in XML format. SOAP defines exactly how a request and its corresponding response must be structured: every message sits inside a fixed “envelope” with a header and a body. As a result, both sides know precisely which fields are expected and with which data type. SOAP is therefore a very formal, contractually governed way of letting programs talk to each other – in contrast to more lightweight approaches such as REST.
In an ERP context, SOAP is a classic integration interface. Through it, an ERP system calls functions of another system or exposes its own functions – for example to hand over orders, query stock levels or send documents to financial accounting. SOAP is older than the REST APIs that dominate today and is considered more heavyweight, but especially strict and well suited to security-critical, transaction-intensive environments. You encounter it above all where established enterprise systems, banks, insurers or large ERP suites are involved.
At a glance
- SOAP = Simple Object Access Protocol, an XML-based messaging protocol
- Every message sits inside a fixed envelope made up of a header and a body
- A WSDL contract describes in machine-readable form which functions and fields exist
- Very strict and strongly typed – but more heavyweight than REST
- Common in ERP with legacy systems, financial and B2B connections
How SOAP works: envelope, XML and WSDL
SOAP follows a clear request-response principle but wraps every message in a strictly predefined structure. At its core is the so-called envelope – an XML wrapper that surrounds every SOAP message. It consists of an optional header, which carries metadata such as authentication or transaction information, and a body, which contains the actual payload or the function call. Because everything is expressed in XML, the messages are verbose and human-readable, but at the same time considerably larger than a compact JSON object.
The actual data exchange usually runs over the web protocol HTTP, but it can also use other transport channels. Unlike REST, SOAP is not tied to HTTP – the protocol defines the message itself, not the path. If an error occurs, the server responds with a structured “SOAP Fault” that describes the error code and cause in machine-readable form. This keeps error handling standardized too and makes it reliably automatable to evaluate.
The role of the WSDL file
A central feature of SOAP is the WSDL file (Web Services Description Language). It describes in machine-readable form which functions a web service offers, which parameters they expect and which data types are returned. The WSDL acts like a technical contract: developers can automatically generate program code for the connection from it, without knowing the internal logic of the target system. This formal self-description is a key reason why SOAP is valued in large, long-lived system landscapes.
SOAP in the ERP system: typical use cases
In an ERP environment, SOAP serves as a bridge between the central system and its surroundings. Classic use cases are connecting to financial and accounting systems, to banks for payment transactions, to freight and logistics providers, or to higher-level corporate systems. Many established ERP suites and industry-specific applications still expose their interfaces as SOAP web services today, because these have been stably documented for years and are embedded in existing processes.
SOAP plays to its strengths especially in B2B business and in regulated industries. Its strict typing and built-in standards for security and transaction safety (such as WS-Security for encrypted, signed messages) make it a reliable choice when data integrity and traceability matter more than maximum speed or lean messages. An ERP that has to connect to a banking system or a government interface often runs into SOAP there.
Distinction: SOAP vs. REST
The most common question in practice is: SOAP or REST? Both are ways for systems to exchange data, but they differ fundamentally in character. SOAP is a complete protocol with strict rules, a fixed XML format and built-in standards for security and transactions. REST (see REST API) is more of a lightweight architectural style that usually uses compact JSON over HTTP and imposes fewer requirements.
As a rule of thumb for the choice: REST is leaner, faster to implement and dominates web and e-commerce connections today, for example between ERP, shop and marketplace. SOAP remains relevant where strict contracts, high security requirements and guaranteed transaction processing matter – or simply because an existing system only offers a SOAP interface. It is not uncommon for an ERP to have to serve both and connect both worlds via middleware.
When SOAP is still the right choice today
For a new integration project, teams usually reach for REST because it is simpler and more broadly supported. SOAP is the right choice when the counterpart mandates it – for instance a legacy ERP, a banking system or a government interface – or when formal contracts, signatures and guaranteed delivery are strictly required. In such cases the higher effort of SOAP is not a drawback but precisely the reason to use it.
DACH relevance and practice: connecting SOAP
In the German-speaking mid-market, you encounter SOAP above all in system landscapes that have grown over many years. Older inventory management and industry solutions, DATEV-adjacent connections, bank and payment interfaces as well as EDI-adjacent B2B processes still frequently rely on SOAP web services. Anyone introducing a modern cloud ERP but needing to keep a legacy system or a major customer with a SOAP interface cannot avoid the technology.
In implementation, the business user rarely handles the connection themselves. Instead, ready-made connectors, middleware or iPaaS platforms are used that translate between SOAP and REST and take over field mapping as well as error handling. For ERP selection, it is decisive whether the system supports the required protocols – ideally both modern REST APIs and SOAP, in order to be able to connect both new cloud services and existing legacy systems.
Example
Example: an ERP connects a banking system via SOAP
A mid-sized wholesaler introduces a new cloud ERP but still has to hand over payment orders to its house bank every day and import account statements. For this, the bank provides only a SOAP web service, whose WSDL describes exactly which fields a payment order must contain and in which format the response comes back.
Instead of programming the interface directly in the ERP, the wholesaler puts a middleware in between. It receives the order data from the ERP via its REST API, wraps it in the required SOAP envelope, signs the message via WS-Security and sends it to the bank. If a SOAP Fault comes back, the middleware reports the error back to the ERP in structured form. In this way the modern ERP and the bank’s strict SOAP system work together reliably, without anyone entering payments manually.
Frequently asked questions
Matching ERP systems
Related services
Questions about SOAP in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.