JSON to XML SOAP Bridge: Envelope, Body, and Namespaces
A SOAP request is not complete when JSON has merely been rendered as XML. The client must build an Envelope and Body, bind the operation namespace, set version-specific HTTP headers, and process Faults. This article shows a controlled SOAP 1.1 wrapper with no real endpoint and does not present an XML converter as a SOAP client.
1. Problem: business XML and a SOAP message are different layers
A business payload describes operation parameters. The SOAP Envelope is the protocol wrapper, Body carries the operation, and a namespace URI identifies the vocabulary. Missing the namespace or placing the payload outside Body can produce a Fault even when the XML is well formed.
2. Minimal reproduction: an Envelope wraps a namespaced operation
This is an abstract SOAP 1.1 shape; urn:example:catalog is only an example namespace. Use the service WSDL or contract for the real operation, parameters, and version.
const body = "<GetPrice xmlns=\"urn:example:catalog\"><sku>book-1</sku></GetPrice>";
const envelope =
"<soapenv:Envelope xmlns:soapenv=\"http://schemas.xmlsoap.org/soap/envelope/\" xmlns:cat=\"urn:example:catalog\">" +
"<soapenv:Body>" + body + "</soapenv:Body>" +
"</soapenv:Envelope>";
console.log(envelope);3. Root cause: namespace, version, and HTTP binding must agree
A prefix is an alias; the namespace URI carries the meaning. Operation elements normally use the URI from the service contract. SOAP 1.1 and SOAP 1.2 use different Envelope URIs and Content-Type values, and a service may require SOAPAction. An XML string alone cannot select these protocol rules.
4. Recommendation: read the WSDL and keep layers separate
Separate JSON validation, business payload, SOAP Envelope, HTTP headers, and Fault parsing. Confirm version, namespace, operation, parameter order, and required headers from the WSDL or contract before using a tested SOAP client or HTTP adapter; never infer the protocol from field names.
5. Complete code: wrap a controlled SOAP 1.1 payload
This function wraps already-generated and validated payload XML and rejects a nested Envelope. It does not send a request, invent an endpoint, or implement WS-Security; those belong to the service contract.
function escapeXml(value: string): string {
return value.replaceAll("&", "&").replaceAll("<", "<").replaceAll(">", ">").replaceAll("\"", """).replaceAll("'", "'");
}
function buildSoap11Envelope(payloadXml: string, operationNamespace: string): string {
if (/<(?:[A-Za-z_][A-Za-z0-9_.-]*:)?Envelope(?:\s|\/?>)/.test(payloadXml)) throw new Error("payload must not contain a SOAP Envelope");
const ns = escapeXml(operationNamespace);
return "<soapenv:Envelope xmlns:soapenv=\"http://schemas.xmlsoap.org/soap/envelope/\" xmlns:op=\"" + ns + "\"><soapenv:Body>" + payloadXml + "</soapenv:Body></soapenv:Envelope>";
}
console.log(buildSoap11Envelope("<op:GetPrice xmlns:op=\"urn:example:catalog\"><op:sku>book-1</op:sku></op:GetPrice>", "urn:example:catalog"));6. Incorrect approaches
Posting ordinary JSON-to-XML output to a SOAP endpoint omits Envelope, Body, or namespaces. Treating a prefix as the namespace URI causes matching failures. Checking only HTTP 200 misses a SOAP Fault, and mixing SOAP 1.1 headers with SOAP 1.2 is invalid.
7. Boundaries: Faults, versions, and security extensions
Success and Fault responses are SOAP XML and must be parsed with the correct Envelope version. WS-Addressing, WS-Security, signatures, clock rules, and attachments are not supplied by a generic XML converter; whether they are required comes from the service contract.
8. Verification
Parse the payload and Envelope as XML, then assert the Envelope URI, Body hierarchy, operation namespace, and required elements. Use WSDL samples or a service test endpoint to verify Content-Type, SOAPAction, Fault mapping, and response namespaces instead of comparing indentation.
9. FAQ
Is valid XML a SOAP client? No; SOAP version, Envelope, namespace, HTTP binding, and Fault handling still have to match.
Can SOAP 1.1 and 1.2 share an Envelope? Not directly; their URIs, Content-Type, and some header rules differ.
Can a WSDL operation be inferred from JSON keys? No; operations and types come from the service contract.
10. Summary
A JSON-to-SOAP bridge should layer the work: generate payload XML from the WSDL, wrap it with the correct versioned Envelope, Body, and namespace, then send it through an HTTP adapter that handles Faults. Ordinary XML conversion is only the representation layer, not a SOAP client.
Sources and further reading
Specifications and references for checking the article’s technical details.
Related articles
JSON to XML: Arrays and Attribute Conflicts
Define array, attribute, text, and repeated-element rules before mapping JSON to XML, with an order example that keeps the input/output contract explicit.
How it worksJSON to XML: Mapping Attributes and CDATA Explicitly
JSON has no native attribute, text, or CDATA semantics. Define explicit keys, escape XML attributes, and split the CDATA ]]> boundary before serialization.
Best practicesJSON over HTTP: Choosing Gzip, Brotli, and Streaming
Separate JSON minification and escaping from HTTP Content-Encoding, then choose Gzip, Brotli, pagination, or NDJSON with a verifiable browser streaming example.
Keep exploring
Use the related browser tool to test the workflow with your own sample data.
Open related tool