Soap Client Laravel Package

Product Decisions This Supports

• Build vs. buy for integration plumbing: adopting phpro/soap-client replaces a hand-rolled SOAP layer (raw ext-soap, cURL, bespoke XML parsing) with a maintained, MIT-licensed foundation. That is a "buy with OSS" decision, and it shifts engineering effort from plumbing to the actual business mapping.
• Feature / roadmap prioritization: SOAP integrations are almost always unblocking work — a payment processor, ERP, carrier, bank, or government gateway that only speaks WSDL. This package directly determines whether those features can be sequenced into the next release or slip a quarter.
• Enterprise / partner connector strategy: if the roadmap includes an "enterprise tier" or partner marketplace, a reusable SOAP client pattern is a prerequisite. This package gives a consistent, typed contract per vendor rather than one-off scripts per integration.
• Vendor selection influence: knowing this package is viable weakens the argument "we must pick the REST vendor." It lets the PM choose the better commercial partner without a technical veto.
• Technical-debt and standardization investment: consolidating scattered new \SoapClient(...) calls into generated, testable, middleware-instrumented clients is a defensible refactor line item with a clear ROI story (logging, retries, auth in one place).
• Observability and compliance spend: the middleware/event model lets a PM justify investment in request/response logging, PII redaction, and audit trails for regulated integrations — implemented once, applied to every SOAP vendor.
• Time-to-market estimates: WSDL-driven code generation compresses integration estimates from weeks to days, which materially changes release dates and staffing plans.

When to Consider This Package

Adopt when:

• You have one or more WSDL-described SOAP services to integrate and expect more over time.
• You need typed request/response objects rather than arrays and stringly-typed XML — code generation produces DTOs your IDE and static analysis can check.
• Integrations require non-trivial transport concerns: WS-Security, mTLS, custom headers, proxies, retries, or per-vendor logging. The middleware/event system handles these without touching generated code.
• You're on modern PHP / Laravel and want the client resolvable from the container, with a clean path to phpro/soap-client-laravel (or equivalent) for config and binding.
• You want testability: the driver abstraction lets you swap in a fake/mock transport instead of hitting a vendor sandbox in CI.
• You value license clarity and maintenance signal: MIT, actively released (latest 2026-05-29), ~890 stars — small but real, agency-backed.

Look elsewhere or reconsider when:

• The integration surface is REST/GraphQL/JSON — this is the wrong tool; use an HTTP client plus a schema/hydration layer.
• It's a single, trivial SOAP call. Native ext-soap is one line; adding a generation pipeline and dependency tree is overkill.
• There is no WSDL (or it's broken/unpublished). Code generation is the core value proposition; without a contract you're back to hand-written XML.
• You have hard latency/throughput constraints — a generated client with middleware and hydration is heavier than a raw call.
• Your CI cannot tolerate generated-code churn, or the vendor revises WSDLs frequently without versioning. Plan for regeneration review, or reconsider.
• You require a commercial SLA / vendor indemnity; OSS support here is community and agency-driven, not contractual.

How to Pitch It (Stakeholders)

For executives: This is a free, permissively licensed (MIT), actively maintained PHP library that turns enterprise and partner SOAP integrations from bespoke engineering projects into a repeatable, low-risk process. It removes weeks of custom plumbing per vendor, reduces integration defects by generating strongly typed clients straight from the vendor's published contract, and concentrates logging, authentication, and retry behavior in one auditable place — which matters for compliance and incident response. There is no license cost and no vendor lock-in; the code is ours to fork if needed. The main risk is ordinary OSS risk (bus factor, upgrade churn), mitigated by the permissive license and a small internal abstraction boundary.

For engineering: Adopt it as the standard SOAP layer. You get WSDL-driven client and DTO generation, a driver abstraction over ext-soap and PSR-18 HTTP clients, and an event/middleware pipeline for auth, logging, caching, and error mapping — so generated code stays untouched and regenerable. It's testable without live vendor calls, integrates cleanly with Laravel's container and config, and leaves an escape hatch to native ext-soap if a specific vendor misbehaves. Budget for regenerating clients when WSDLs change and for pinning versions in composer.json.