When You’ll See SOAP

SOAP is “dead” for new APIs but very alive in regulated industries and existing enterprise systems. Knowing where it lives helps you anticipate it (and prepare to work around it).

Industries where SOAP is still common

Banking and payments

• SWIFT — international wire transfers; messages historically MT/MX (not strictly SOAP but XML-based, similar enterprise vibe).
• ACH and wire integration — many bank APIs for corporate banking still expose SOAP.
• Payment gateways — older ones (Authorize.Net SOAP API), some regional processors.
• Card processing — TSYS, FirstData, FIS still have SOAP endpoints alongside newer REST.

Government / public sector

• Tax filing — many countries’ e-filing systems use SOAP (US IRS Modernized e-File, UK HMRC older APIs, EU customs).
• Customs / shipping declarations — older WCO standards use SOAP.
• Land registry, court filings — long-running systems on SOAP.
• Identity verification (KYC) services — often SOAP.

Healthcare

• HL7v3 — XML-based health data exchange; CDA documents.
• HIE (Health Information Exchanges) — connections often use SOAP with WS-* security.
• Drug interaction databases — pre-FHIR APIs were SOAP.
• Insurance claim submission (X12 wrappers in SOAP).

FHIR (REST-based) is replacing HL7v3 SOAP in new healthcare integrations, but legacy is widespread.

Telecom

• Provisioning systems — activating SIM cards, changing plans.
• Billing integrations — Amdocs, Ericsson BSS systems.
• Number portability — regional registry APIs.

Logistics and shipping

• UPS, FedEx, DHL — all had SOAP APIs (newer REST exists, but SOAP often still mandatory for some operations).
• Freight forwarders — EDI-over-SOAP common.
• Customs brokerage.

Enterprise software

• SAP — many SAP integrations use SOAP (PI/PO, BAPI as web services).
• PeopleSoft, Oracle E-Business Suite — extensive SOAP APIs.
• Microsoft Dynamics — older versions; newer use OData / REST.
• Salesforce SOAP API — alongside the REST API; still used.
• Older Workday / NetSuite APIs.

Telecommunications standards

• OSS / BSS systems in telecom.
• TMF (TM Forum) Open APIs — newer ones are REST, older are SOAP.

Why SOAP persists

1. Sunk cost — billions invested in SOAP systems; rewriting isn’t cheap.
2. Compliance — auditors / regulators trained on WS-Security signed messages.
3. Tight contracts — WSDL’s strict typing matters in money-moving systems.
4. Audit trails — message-level signing creates non-repudiable history.
5. Reliable messaging — WS-ReliableMessaging for guaranteed delivery (rare elsewhere).
6. Enterprise vendor inertia — IBM, Microsoft, Oracle built whole stacks; customers don’t migrate.

For greenfield startup APIs, none of these matter. For a Python developer integrating with a bank, all of them.

What to expect when integrating with SOAP

The typical journey:

1. Get the WSDL — sometimes a URL, often an email attachment.
2. Set up Zeep — point at the WSDL; inspect operations.
3. Auth setup — username/password, X.509 cert, sometimes SAML. Usually involves a sandbox vs production cert.
4. First call — usually fails. Look at the actual XML; compare to docs.
5. Sandbox tests — most providers have a test environment with synthetic data.
6. Production access — additional onboarding: signed agreements, IP whitelisting, security review.
7. Error handling — old systems return cryptic fault codes; build a translation layer.
8. Monitoring — SOAP services have downtime; expect to handle retries and degraded modes.

Common challenges

“It works in SoapUI but not in Python”

Often namespace handling. SoapUI is forgiving about namespace declarations; Python libraries are strict (per spec). Inspect the raw XML on both sides and compare.

“The WSDL imports another WSDL that I don’t have”

Many enterprise WSDLs reference internal schema URLs. Get all referenced files; Zeep can load from local files via Client("/path/to/main.wsdl") if all imports resolve.

“The service requires WS-Security but my certs aren’t accepted”

Cert chain issues, intermediates missing, wrong cert type (some services want PKCS#12 with a passphrase). Test against the sandbox first; many provide test certs.

“Timestamps fail validation”

Clock skew. NTP-sync your servers. Set the WS-Security Created/Expires window appropriately.

“Response is HTTP 200 but contains an error”

Pre-fault-aware services return HTTP 200 with an error in the body, not a proper SOAP Fault. Check application-level success markers; don’t just check HTTP status.

“Performance is terrible”

XML parsing, large envelopes, many round trips. Optimizations:

• Cache the WSDL (don’t parse on each Client construction).
• Reuse the Client across requests.
• Parallelize independent calls.
• For high-throughput, accept that SOAP isn’t fast and design around it (queues, batch operations).

Modernization strategy — the wrapper pattern

The standard approach when you must consume a SOAP service but want modern API surface:

┌─────────────────────────┐
│ Modern clients          │
│ (web, mobile, partner)  │
└─────────────────────────┘
             ↓ REST / GraphQL
┌─────────────────────────┐
│ Adapter (Python FastAPI │
│  + Zeep)                │
└─────────────────────────┘
             ↓ SOAP
┌─────────────────────────┐
│ Legacy SOAP service     │
└─────────────────────────┘

The adapter:

• Translates JSON to XML and back.
• Maps SOAP Faults to REST error responses.
• Caches expensive SOAP calls (responses are slow).
• Adds modern auth (JWT bearer) instead of forcing clients into WS-Security.
• Provides OpenAPI / GraphQL schema for the modern surface.

This pattern lets you modernize the API surface without changing the underlying systems.

When you’d build a new SOAP service

Almost never, but valid reasons:

1. A partner mandates SOAP and won’t accept REST. Build the SOAP service, but consider also providing REST internally.
2. Regulatory requirement — some compliance frameworks explicitly require WS-Security / SOAP envelopes.
3. Legacy system integration where the legacy side is SOAP-only and you want the integration code on your side.

In those cases: Python isn’t a great choice. C#, Java have better SOAP server support. If forced to Python: Spyne is the option (04_python_libraries.md).

Common interview confusions

• “SOAP is dead and replaced by REST.” — for new APIs yes; for existing enterprise integrations it’s not going anywhere.
• “All banks now have REST APIs.” — most have both. Often new features are REST-only; legacy features stay SOAP.
• “You can avoid SOAP by choosing a different provider.” — sometimes yes (consumer-facing). For regulated B2B (banks, insurers, government), the SOAP provider is the only option.

Interview angle

• “Why does SOAP still exist?” — installed base in banking, government, healthcare, telecom, ERP. Decades of investment, compliance/audit requirements, and tight contracts via WSDL. Replacing existing SOAP systems isn’t cost-effective.
• “Where would you most likely encounter SOAP today?” — bank corporate APIs, government tax/customs systems, healthcare HIE, telecom provisioning, ERP integrations (SAP, PeopleSoft), older payment processors, freight/customs APIs.
• “How do you modernize a SOAP integration?” — wrap with a Python adapter exposing REST/GraphQL to modern clients. The adapter uses Zeep to call the SOAP service. Clients see modern auth (JWT) and JSON; SOAP stays inside.
• “What’s tricky about consuming a legacy SOAP service?” — namespace strictness, WSDL imports of other WSDLs, certificate handling for WS-Security, clock skew on timestamps, pre-fault-aware errors returning HTTP 200 with in-body errors, performance.
• “Should you build a new SOAP service?” — almost never. Only if a partner mandates it or a regulation explicitly requires WS-Security/SOAP envelopes. In which case Python isn’t ideal — Java/.NET have better SOAP server frameworks.
• “Tell me about a time you integrated a SOAP service.” — talk through Zeep setup, sandbox testing, certificate management, error handling, monitoring. Mention the wrapper pattern if you abstracted it behind REST.