Compliance & StandardsGlossary

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

Free Tool

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)

ITAR compliant AI governance for export-controlled data: acceptable use policy, access controls and audit trails that keep ITAR and EAR data out of public LLMs.

Working with SOAP in a live environment? Our engineers do this every day - and our AI agents automate most of it.

Talk to an Expert Browse the Full Glossary

Back to Glossary

Try it here, free

SyteLine IDO SOAP Web Service Client Generator

Open full tool

Generate a working C# console client and a PowerShell equivalent for the Mongoose IDO SOAP web service on on-premises SyteLine.

Fill in

Service URL

Confirm the .asmx path on your utility server; open it with ?WSDL to check.

User

Environment variable holding the password

Configuration name

IDO to load

Property list

Filter

Order by

Record cap (-1 = 200, 0 = all)

IDO that publishes the method

Method name

Method input 1

Method input 2

Generated code

Free, optional. Reopen it on any device.

Download:

1. C# console client (service reference named IDOWebService)

// Add a service reference to http://utilserver/IDORequestService/IDOWebService.asmx?WSDL with namespace IDOWebService.
using System;
using System.Data;
using System.ServiceModel;

class Program
{
    static void Main()
    {
        // Use BasicHttpSecurityMode.Transport when the URL is https.
        var binding = new BasicHttpBinding(BasicHttpSecurityMode.None) { MaxReceivedMessageSize = 10485760 };
        var client = new IDOWebService.DOWebServiceSoapClient(binding, new EndpointAddress("http://utilserver/IDORequestService/IDOWebService.asmx"));

        string password = Environment.GetEnvironmentVariable("SL_PASSWORD");
        string token = client.CreateSessionToken("svc_integration", password, "CSI_PROD");

        // Session token, IDO, properties, filter, order by, post-query method, record cap
        DataSet ds = client.LoadDataSet(token, "SLItems", "Item, Description, UM", "Item LIKE 'PN-%'", "Item", "", -1);

        DataTable table = ds.Tables[0];
        foreach (DataRow row in table.Rows)
        {
            foreach (DataColumn col in table.Columns)
            {
                Console.Write(col.ColumnName + "=" + row[col] + "  ");
            }
            Console.WriteLine();
        }

        // CallMethod: parameters travel as XML, in method order. ByRef='Y' marks output parameters.
        // XML-escape any value that can contain < > & or quotes.
        string parms = "<Parameters>"
            + "<Parameter ByRef='N'>PN-48213</Parameter>"
            + "<Parameter ByRef='N'>MAIN</Parameter>"
            + "<Parameter ByRef='Y'/>"
            + "<Parameter ByRef='Y'/>"
            + "</Parameters>";

        object rc = client.CallMethod(token, "UETItemChecks", "UETItemReorderCheckSp", ref parms);
        Console.WriteLine("Return value: " + rc);
        Console.WriteLine("Parameters after call: " + parms);
    }
}

2. PowerShell equivalent (Windows PowerShell 5.1)

# New-WebServiceProxy exists in Windows PowerShell 5.1, not in PowerShell 7.
$svc = New-WebServiceProxy -Uri 'http://utilserver/IDORequestService/IDOWebService.asmx?WSDL'
$cred = Get-Credential -UserName 'svc_integration' -Message 'SyteLine password'
$token = $svc.CreateSessionToken($cred.UserName, $cred.GetNetworkCredential().Password, 'CSI_PROD')

$ds = $svc.LoadDataSet($token, 'SLItems', 'Item, Description, UM', "Item LIKE 'PN-%'", 'Item', '', -1)
$ds.Tables[0] | Format-Table -AutoSize

$parms = "<Parameters><Parameter ByRef='N'>PN-48213</Parameter><Parameter ByRef='N'>MAIN</Parameter><Parameter ByRef='Y'/><Parameter ByRef='Y'/></Parameters>"
$ref = [ref]$parms
$rc = $svc.CallMethod($token, 'UETItemChecks', 'UETItemReorderCheckSp', $ref)
"Return value: $rc"
"Parameters after call: " + $ref.Value

Signatures follow the Mongoose IDO web service documentation: CreateSessionToken(user, password, configuration), LoadDataSet(token, IDO, properties, filter, order by, post-query method, record cap) and CallMethod(token, IDO, method, ref XML parameters). Verify the .asmx path on your server, check parameter names and order against the WSDL, and confirm the client class name Visual Studio generates from it (DOWebServiceSoapClient is typical for the DOWebService class). The default method is the custom example from the companion stored procedure generator; replace it with a real method on your IDO.

Check your SOAP integration

Send the generated client and your SyteLine version; we will confirm the service path, token handling and method parameters.

Optional. The tool and every export work without this. No spam.

ArchRay builder

Design the on-prem AI stack: model, GPUs, RAG pipeline, guardrails

See memory, speed and cost as you swap parts, then export the diagram. Free, in your browser.

What Is SOAP?

SOAP Explained

Why It Matters

In Practice

Frequently Asked Questions

What is the difference between SOAP and REST?

Why do ERP systems still use SOAP?

Related Terms

API (Application Programming Interface)

REST API

Middleware

Go Deeper

ITAR Compliance Checklist for Manufacturers

CMMC-Compliant AI Deployment: What Level 2 Contractors Must Know

AI Governance for Export-Controlled Data (ITAR/EAR)

Fill in

1. C# console client (service reference named IDOWebService)

2. PowerShell equivalent (Windows PowerShell 5.1)

Check your SOAP integration

Keep exploring

Free tools

ERP fixes and how-tos

Guides

Fill in

1. C# console client (service reference named IDOWebService)

2. PowerShell equivalent (Windows PowerShell 5.1)

Check your SOAP integration