Actually, that's what an automated translation would look like. A human would likely represent this as follows: { "errorCode "SCE013" } That SOAP envelope i

Actually, that's what an automated translation would look like. A human would likely represent this as follows: { "errorCode "SCE013" } That SOAP envelope is 99% just telling you it's a SOAP envelope, which technically is completely redundant because presumably you'd be aware of the fact that you are talking to a SOAP API. And apparently they had no schema for actually telling you anything meaningful about the error. Which is why it is represented as a string with an error code. That string is the only useful bit of information in the message. Basically the SOAP equivalent of Internal Server Error. From a parsing point of view it's horrible because all those namespaces need to be resolved and the schemas need to be processed. And of course a lot of those namespace urls don't actually have servers behind them that serve those schemas. Most of those urls never resolved to anything useful at all. The servers that were supposed to host those schemas never existed. Alternatively you just ignore all that crap and pick the message apart with XPath or a regular expression. That's what I used to do when dealing with SOAP APIs. Most of those APIs were just stupendously convoluted RPC wrappers anyway from some bit of enterprise crap ware. I never could be bothered to treat those systems with the respect they demanded from me. Way faster to just sidestep all that nonsense. Send a message, pick apart what comes back to determine success / failure and move on with your life. That's why SOAP died. Because as soon as people caught up to this being the optimal way to deal with SOAP, the next logical thing was to get rid of it entirely.