Part 6: Error Handling and SOAP Faults

Why SOAP Error Handling Deserves Its Own Article

Most REST API tutorials cover error handling in a few paragraphs: return the right HTTP status code and a JSON body with a message. SOAP errors are more formal, more structured, and — if you do not understand them — more confusing.

When I first worked with a SOAP payment gateway, my client code crashed with zeep.exceptions.Fault: Server and no further context. The SOAP Fault had a detailed <detail> element with a typed error code and description, but I was not extracting it. Once I understood how SOAP Faults are structured and how zeep surfaces them, I could build proper error handling and give meaningful feedback in my application.

This part covers SOAP Fault structure, the differences between SOAP 1.1 and 1.2 faults, how to raise typed faults in spyne, and how to handle them defensively in zeep clients.

SOAP Fault Structure

A SOAP Fault is a standardised way of communicating errors from a service to a client. When a fault occurs, the SOAP body contains a <soap:Fault> element instead of the normal response.

SOAP 1.1 Fault

<soap:Body>
    <soap:Fault>
        <faultcode>soap:Server</faultcode>
        <faultstring>Product not found: SKU-999</faultstring>
        <faultactor>http://example.com/inventory</faultactor>
        <detail>
            <inv:ProductError xmlns:inv="http://example.com/inventory">
                <inv:ErrorCode>PRODUCT_NOT_FOUND</inv:ErrorCode>
                <inv:ProductId>SKU-999</inv:ProductId>
                <inv:Message>No product exists with this identifier</inv:Message>
            </inv:ProductError>
        </detail>
    </soap:Fault>
</soap:Body>

SOAP 1.1 Fault elements:

Element
Required
Purpose

faultcode

Yes

Categorises the fault. Standard values below.

faultstring

Yes

Human-readable description

faultactor

No

URI identifying which node in the message path raised the fault

detail

No

Application-specific error details (any XML structure)

Standard faultcode values in SOAP 1.1:

Code
Meaning

soap:VersionMismatch

SOAP namespace mismatch

soap:MustUnderstand

A mandatory header was not understood

soap:Client

The fault is caused by the client (bad input, auth failure)

soap:Server

The fault is caused by the server (internal error, database failure)

SOAP 1.2 Fault

SOAP 1.2 restructured faults to be more precise:

SOAP 1.2 replaced faultcode with a structured Code/Value/Subcode hierarchy. Standard top-level codes:

Code
Meaning
SOAP 1.1 equivalent

soap:VersionMismatch

SOAP version mismatch

Same

soap:MustUnderstand

Mandatory header not understood

Same

soap:Sender

Client-side fault

soap:Client

soap:Receiver

Server-side fault

soap:Server

soap:DataEncodingUnknown

Unknown encoding

New in 1.2

Raising Faults in spyne

Built-in spyne Errors

spyne provides a set of common errors that automatically map to SOAP Faults:

Usage:

spyne serialises these Python exceptions into properly formatted SOAP 1.1 or 1.2 Fault elements automatically.

Custom Typed Faults

For B2B integrations, generic error messages are often not enough. Partners may need a structured error with a machine-readable code, a tracking ID, and contextual information. Define custom fault types using ComplexModel:

Use the custom faults in the service:

The resulting SOAP Fault XML sent to the client will contain the typed detail:

Handling Faults in zeep Clients

zeep raises zeep.exceptions.Fault when the server returns a SOAP Fault response.

Basic Fault Handling

Extracting Typed Fault Details

When the fault <detail> contains a structured XML element, extract it with XPath or direct attribute access:

Distinguishing Client vs Server Faults

soap:Client faults indicate the request was invalid — the client should not retry. soap:Server faults indicate a server-side failure — the request may be retried.

Handling Multiple Fault Types

When a service declares multiple fault types in the WSDL, distinguish them by error code or detail element name:

Logging Faults

Always log SOAP faults with enough context to diagnose issues without exposing sensitive data:

Mapping SOAP Faults to REST Responses

When building a REST-to-SOAP proxy or a REST API backed by a SOAP service, you need to translate SOAP Faults into HTTP status codes:

What's Next

You can now:

  • Understand SOAP 1.1 and 1.2 Fault structures

  • Raise typed faults in spyne with structured detail elements

  • Catch and parse faults in zeep clients

  • Build fault-aware retry logic that distinguishes client vs server errors

  • Map SOAP faults to HTTP responses in REST proxies

In Part 7, we cover testing SOAP services with pytest, performance tuning, and patterns for integrating SOAP into modern architectures.

Last updated