What Is SOAP?
Also known as: SOAP API, SOAP web service, WSDL service
Definition
SOAP is an XML-based messaging protocol for exchanging structured information between systems, in which each message is an envelope containing an optional header and a body, and the available operations are formally described by a WSDL contract.
SOAP Explained
SOAP originally stood for Simple Object Access Protocol, though the acronym was dropped in version 1.2 as the protocol grew well beyond simple object access. A SOAP message is an XML document with an Envelope root element containing an optional Header for metadata such as security tokens, transaction context, or routing information, and a mandatory Body carrying the payload. Errors are returned in a standardized Fault element rather than through transport status codes, which is one of the clearest differences from REST.
The contract is the defining feature. A Web Services Description Language document formally describes the service: available operations, the message structures for input and output, the data types defined by XML Schema, the binding to a transport, and the endpoint address. Because the contract is machine-readable and strictly typed, tooling can generate client proxies automatically, and a message that violates the schema can be rejected before any business logic executes. That strictness is an advantage in regulated exchange and a burden during rapid iteration.
The WS-* specification family layered enterprise capabilities on top of the base protocol. WS-Security provides message-level signing and encryption plus token propagation, meaning a message can remain protected across multiple intermediaries rather than only in transit between two endpoints. WS-ReliableMessaging provides guaranteed, ordered delivery. WS-AtomicTransaction supports distributed two-phase commit. These capabilities are why SOAP still holds ground in banking, government, healthcare, and defense interfaces where message-level assurance is a requirement rather than a preference.
SOAP is transport-agnostic in principle, but in practice almost all SOAP traffic is HTTP POST, with a SOAPAction header indicating the operation. Payloads are substantially larger than JSON equivalents because of XML verbosity and envelope overhead, and parsing costs more CPU. For high-volume, low-latency, mobile-facing scenarios these costs are decisive, which is why greenfield public APIs are almost never SOAP today.
In ERP environments SOAP is not legacy trivia - it is operational reality. Infor SyteLine and Mongoose applications expose IDO operations through SOAP-based web services that remain in production across many installations. Older Baan and LN integration layers, EDI translators, banking interfaces, tax engines, and government submission portals frequently expose SOAP endpoints only. Integration teams therefore routinely bridge the two worlds, exposing a REST facade to modern consumers while a middleware layer speaks SOAP to the system of record.
Why It Matters
- Many production ERP interfaces, including SyteLine IDO web services and government portals, are SOAP-only, so the skill remains necessary.
- WSDL contracts and XML Schema validation catch malformed messages before business logic runs, reducing bad data entering the ERP.
- WS-Security provides message-level protection that survives intermediaries, which transport-only TLS cannot offer in multi-hop exchanges.
- XML verbosity and parsing cost make SOAP a poor fit for high-volume or mobile-facing integrations, driving hybrid architectures.
In Practice
A frequent gotcha when calling SyteLine IDO web services: the session token from the authentication call must be reused across subsequent operation calls, and failing to reuse it opens a new session per request. High-volume integrations written without token reuse exhaust licensed sessions and begin failing under load while working perfectly in test. Cache the token, refresh it on expiry, and explicitly release sessions when a batch completes.
Frequently Asked Questions
What is the difference between SOAP and REST?
SOAP is a protocol with a strict XML envelope, a formal WSDL contract, standardized faults, and optional WS-* extensions for message-level security, reliable delivery, and distributed transactions. REST is an architectural style using plain HTTP verbs, URIs, status codes, and usually JSON. SOAP offers stronger built-in enterprise guarantees; REST offers lower overhead and far simpler tooling.
Why do ERP systems still use SOAP?
Because the interfaces were built when SOAP was the enterprise standard and they still work. Replacing a stable, contract-defined integration layer that supports hundreds of installations carries real risk and little immediate benefit. Vendors typically leave SOAP endpoints in place for compatibility and add REST gateways alongside them, so both coexist in most mature ERP landscapes.
Related Terms
API (Application Programming Interface)
An API (Application Programming Interface) is a defined contract that lets one software system request data or trigger functions in another, specifying the available operations, the structure of requests and responses, and the rules for authentication and error handling.
REST API
A REST API is a web interface that exposes application data as addressable resources over HTTP, using standard verbs such as GET, POST, PUT, PATCH, and DELETE, stateless requests, and conventional status codes, typically exchanging JSON.
Middleware
Middleware is software that sits between applications and handles the communication, transformation, routing, and reliability concerns of moving data between them, so that the applications themselves do not need to know about each other directly.
Go Deeper
ITAR Compliance Checklist for Manufacturers
A 32-point checklist covering DDTC registration, technical data controls, foreign person access, IT security, and recordkeeping for ITAR-regulated manufacturers.
CMMC-Compliant AI Deployment: What Level 2 Contractors Must Know
CMMC-compliant AI deployment explained: how Level 2 defense contractors can run AI on CUI without expanding assessment scope. Controls, enclaves, and costs.
AI Governance for Export-Controlled Data (ITAR/EAR)
AI governance for export-controlled data: policies, access controls, and audit trails that keep ITAR and EAR data out of public LLMs and off foreign servers.
Working with SOAP in a live environment? Our engineers do this every day - and our AI agents automate most of it.