Product Decisions This Supports
- Build vs. buy for legacy integrations: SOAP is almost always a "must integrate, must not hand-roll" situation — ERP (SAP), payment gateways, shipping/customs, banking, government/healthcare (HL7, NHS, tax authorities). This package lets you commit to a thin, testable adapter layer instead of a bespoke cURL/XML stack, and gives engineering a consistent
Soap facade, generated client classes, request/response hooks, and Soap::fake() for tests.
- Scoping and estimation: if the integration surface is a handful of WSDLs with modest call counts, adopting this package shortens the build materially. If you need WS-Security, MTOM/attachments, or exotic WS-* policies, budget for custom hooks or a different transport — don't assume the package covers it.
- Framework upgrade planning (new in 4.0.0): this release drops Laravel 11 and adds Laravel 13. That is a hard coupling your roadmap now has to absorb. Concrete decisions:
- Any product line still on Laravel 11 cannot take this upgrade — you are pinned to
^3.0 and will be carrying an unsupported dependency branch.
- Laravel 12 teams can move to 4.0.0 cleanly (verify the constraint allows 12; if only 13 is supported, treat that as a blocker).
- Laravel 13 adoption is now unblocked by this package — remove it from your "blocked on dependencies" list.
- Upgrade sequencing: schedule this bump as a discrete, low-effort PR in the same window as the framework upgrade, not bundled with feature work. Because the changelog shows no API/behaviour changes, the risk is version-constraint resolution, not code changes — so it's cheap and should not be deprioritised.
- Vendor and maintenance risk: 4.0.0's only substantive change is a Laravel version bump, contributed by a first-time contributor. That's a signal the package tracks the framework reactively and with limited maintainer bandwidth — factor it into your dependency register and decide whether you're comfortable with a single-maintainer, agency-owned dependency on a revenue-critical integration path.
When to Consider This Package
Adopt when:
- You have SOAP/WSDL endpoints you don't control and must keep working for the foreseeable future (enterprise, regulated, or government counterparties).
- You're on a Laravel version the release supports — for 4.0.0 that means Laravel 12 or 13; Laravel 11 users must stay on 3.x.
- You want Laravel-idiomatic ergonomics — client classes via generator, fluent request building, hooks for logging/auth/retry, and first-class faking so integration tests don't hit the wire.
- The integration is contained: a defined set of operations, no streaming/attachment requirements, no complex WS-Security negotiation.
- You value speed-to-first-call over absolute control of the XML envelope.
Look elsewhere (or wrap with something lower-level) when:
- You need WS-Security, X.509 signing, MTOM/Swagger attachments, or WS-Addressing — evaluate
php-soap/php-soap (ext-soap based) or a hand-rolled ext-soap client.
- Laravel 11 is still in your support matrix with no upgrade date. Don't fork the constraint; stay on 3.x and plan the framework upgrade.
- The counterparty offers REST/JSON — do not adopt SOAP tooling for a problem you don't have.
- You require a commercially supported dependency with an SLA. This is an agency-maintained open-source package; if the integration is business-critical, budget for the ability to fork and maintain it.
- You need guaranteed long-term support windows — the pattern of dropping a Laravel major each release means forced upgrade cadence on their schedule, not yours.
How to Pitch It (Stakeholders)
For executives: We have integrations with counterparties who only speak SOAP — ERP, payments, and a regulator. Rather than build and maintain that plumbing ourselves, this package gives us a small, tested adapter layer in our existing Laravel codebase, with built-in test support so we're not manually verifying XML against a live third party. The trade-off is dependency on a small open-source project; the code is thin and forkable, so that risk is manageable and cheaper than the alternative.
For engineering: 4.0.0 is a compatibility release — adds Laravel 13, drops Laravel 11, no API changes. If you're on 12 or 13, bump the constraint and ship it; if you're on 11, stay on 3.x until the framework upgrade lands. It gives us generated SOAP client classes, fluent calls, before/after hooks for auth and logging, and Soap::fake() in tests — which is the main reason to use it over raw ext-soap. Caveat: no WS-Security or attachments, and it's maintained by a single agency, so keep the integration behind our own interface so we can swap the transport if needed.