Soapy Laravel Package

Product Decisions This Supports

• Build vs. buy for SOAP integrations. Soapy is a Laravel-native wrapper around PHP's SoapClient that generates client classes from a WSDL and wires them into the container/config. The decision it supports: do we hand-roll XML request building, envelope/header plumbing, and response parsing for each partner, or do we adopt a small purpose-built adapter? For most teams the package wins — the code it replaces is tedious, easy to get subtly wrong (namespaces, soapAction, fault handling), and has no product differentiation.
• Legacy/enterprise partner onboarding. SOAP is still the contract for a lot of ERP, payment gateway, shipping/logistics, banking, tax/government filing, and healthcare-eligibility APIs. This package is the "how do we integrate with vendor X quickly" answer when vendor X hands us a .wsdl.
• Platform upgrade unblocking. v3.1.0 is a compatibility release: PHP 8.4 support and Laravel 12 support. That directly feeds the roadmap decision "can we move the application to Laravel 12 / PHP 8.4 this quarter?" — if this dependency were stranded on an older framework line, it would have been either a migration blocker or a forced rewrite.
• Keep-vs-replace on the integration layer. A maintained release cadence is a proxy for whether the SOAP edge of our architecture is safe to leave in place for another 12–18 months versus spending roadmap capacity converting partners to REST (which usually isn't ours to decide anyway).
• Use cases to scope: typed client generation per WSDL, per-environment endpoint/config switching, and facade-style access inside services and jobs — i.e., SOAP becomes a normal injected dependency rather than a special case with bespoke glue.

When to Consider This Package

Adopt when most of the following are true:

• You are on Laravel and must integrate with one or more SOAP/WSDL services (not REST, not GraphQL).
• You are on, or planning to move to, Laravel 11/12 and PHP 8.1–8.4 — v3.1.0 is what makes the top of that range viable.
• The integration is request/response and synchronous; you want generated client stubs and Laravel config conventions instead of raw SoapClient calls scattered through the codebase.
• You want the SOAP surface isolated behind an interface you control, so partner swaps and a future REST migration are a code change, not a rewrite.

Look elsewhere (or plan extra work) when:

• No SOAP in the estate. If the roadmap is entirely REST/JSON, adopting this adds a dependency with no payoff.
• You need advanced WS- features.* WS-Security/SAML assertions, MTOM/XOP attachments, WS-Addressing, or reliable messaging are not the package's stated focus in this release. Validate against your partner's actual WSDL requirements before committing; if you need these, you may be writing custom SoapHeader/SoapClient subclasses anyway, at which point the package is a thin convenience rather than a foundation.
• The integration is tier-1 revenue-critical and you need a support contract. This is a small, single-vendor open-source project. Its release history is a compatibility-release history (v3.0.0 → v3.1.0 is framework support only), which is healthy for stability but means feature velocity and commercial backing are limited. Mitigate with contract tests and an owned abstraction layer, or budget for in-house maintenance.
• Streaming, async, or very high-throughput partner traffic where a generic WSDL client won't give you the connection pooling, retry, or payload control you need.
• The vendor also offers REST/JSON. Prefer the REST path; don't adopt SOAP tooling for a partner who has a modern API.

How to Pitch It (Stakeholders)

For executives (one paragraph): We need to talk to partners who only expose SOAP/XML APIs. Soapy is a small open-source Laravel package that generates the client code for those APIs and plugs it into our app's configuration, so we're not paying engineers to hand-write XML plumbing for each partner. The v3.1.0 release contains no new features and no breaking changes — it exists solely to add support for PHP 8.4 and Laravel 12. That matters to us for one reason: it clears a dependency from the path of our framework upgrade, at effectively zero cost and zero migration risk. The trade-off is that this is a niche, thinly-maintained project, so we'll keep our partner integrations behind our own interface so we can replace the package without touching product code.

For engineering leads:

• What changed: two compatibility PRs (PHP 8.4, Laravel 12) plus a version tag. Minor version bump, no deprecations, no API changes, nothing to migrate.
• What it means: we can carry this dependency across the Laravel 12 / PHP 8.4 upgrade instead of blocking on it or forking it. Treat the upgrade ticket as unblocked.
• How to use it well: one generated client class per WSDL, checked in or generated at build time (decide and document which — regeneration drift is the main day-two footgun); endpoint and credentials via config/env, never hardcoded; wrap each client in a domain-level interface so callers don't depend on the package directly.
• What to verify before relying on it: WS-Security/attachment support against the specific partner WSDL, error/fault mapping into our exception conventions, timeout and retry behaviour at the HTTP layer, and test strategy (record/replay fixtures rather than hitting partner sandboxes).
• Risk to track: maintainer concentration and release cadence. Re-evaluate if a framework upgrade ships and this package lags more than one Laravel major behind.