Soap Client Laravel Package

Technical Evaluation

Architecture fit. This is not a Laravel package in any meaningful sense — no service provider, no publishable config, no facade, no container bindings, no queue/event integration. It is a standalone PHP SOAP wrapper, and a thin one at that: most of the actual protocol work is delegated to PHP's ext-soap and the Salesforce enterprise/partner WSDL. The genuine intellectual property is small — session header management, login/logout lifecycle, and some convenience methods. That matters for the build-vs-buy call: replacing it is not a rewrite of a complex system, it is a rewrite of a few hundred lines.

Integration feasibility. Composer-level installability is the first gate and the most likely blocker. A package last released in 2015 will almost certainly carry a PHP constraint in the 5.4–5.6 range and possibly PSR-0 autoloading, which conflicts with Laravel 9/10/11 on PHP 8.1+. Expect to either fork and patch the constraint, or vendor the source into app/Services and abandon Composer management. Either way you are now the maintainer on day one.

Technical risk. Concentrated and mostly non-obvious:

• API version retirement. Salesforce retires SOAP API versions on a rolling cadence. A client frozen in 2015 is pointed at a version that is very likely already unsupported; the WSDL must be regenerated and the generated stubs re-verified against modern responses.
• PHP 8.x drift. SoapClient option handling, dynamic property deprecation, each()/create_function style constructs, and stricter type coercion are all plausible breakages.
• Credential handling. These older clients typically take username/password/security-token inline. That is a secrets-management conversation with your security team before anything else happens.
• No test suite of consequence. With 1 star and 0 dependents, there is no community vetting, no CVE surface, and no evidence of production use anywhere.
• Silent failure. Hand-rolled SOAP layers frequently return raw stdClass trees and let faults bubble as SoapFault rather than domain exceptions, which undermines Laravel's exception handler and Horizon-style observability.

Key questions I would put to the team before a single line of code:

1. Which Salesforce operations actually need SOAP? Partner WSDL convertLead, certain metadata/describe calls, and some legacy org flows are SOAP-only, but the majority of CRUD is better served by REST or Bulk API 2.0.
2. Is ext-soap present in the runtime image, and will platform/security approve it?
3. What Salesforce API version does the target org require, and is there a hard deadline tied to a retirement date?
4. Who owns the fork? Name a person, not a team.
5. What is the volume and record-size profile — this determines whether SOAP is viable at all versus Bulk.

On the opportunity score. The 4.16 opportunity figure reads as a measurement of demand for Salesforce integration work, not of this package's quality. Do not let it override the maintenance signals — 1 star and 0 dependents on a decade-old repo is a clear abandonment signal.

Integration Approach

Stack fit. Poor as a dependency, workable as a reference implementation. The correct pattern in a modern Laravel codebase is a boundary: a SalesforceGateway interface in the domain layer with a SOAP adapter behind it. That way, when the SOAP decision is revisited — and it will be — the swap is contained to one class.

Migration path. Sequence this as an evaluation, not an adoption:

1. Two-day spike in a scratch container. Install the package, hit a Salesforce sandbox, confirm whether the WSDL even parses under your PHP version. Most projects will fail here, and failing cheaply is the point.
2. Prefer the alternatives. saloonphp/saloon with a Salesforce connector, omniphx/forcedotcom, or a direct Laravel Http client against the REST API covers the bulk of use cases with better testability, PSR-18 compliance, and active maintenance. Where SOAP is genuinely required, a hand-written SoapClient wrapper with a freshly fetched WSDL is roughly the same effort as patching this package and carries far less baggage.
3. Reserve this package for the narrow case: a small, stable, low-volume set of SOAP-only operations where the 2015 code still runs unmodified. Vendor it, pin it, and annotate why.

Compatibility. Validate three things specifically: PHP constraint vs your runtime, TLS 1.2+ handshake against Salesforce endpoints (older clients sometimes hardcode SOAP_1_1 with lax SSL context options), and whether the WSDL is fetched at runtime or cached — runtime fetches are a latency and availability coupling you do not want in a request path.

Sequencing. Auth and secrets first, then a read-only describe call, then one write operation in sandbox, then contract tests, then production behind a feature flag. Do not parallelize the auth work with the object-mapping work; the credential model constrains everything downstream.

Operational Impact

Maintenance. You inherit the full maintenance burden. Salesforce ships three releases a year; each one can shift WSDL definitions and deprecate fields. Budget an ongoing line item — realistically a few days per quarter for WSDL regeneration and regression testing — and assign it to a named owner. A dormant upstream means no security patches arrive; every future CVE in the dependency chain is yours to triage manually.

Support. Effectively zero. One star, zero dependents, no issue activity since 2015. There is no vendor escalation path, no maintainer responsiveness, and no community knowledge base. Internal documentation of the wrapper becomes mandatory, not optional.

Scaling. SOAP is a synchronous, per-record API with 24-hour request quotas and concurrency limits. It does not batch. If the use case involves bulk sync, backfills, or high-frequency record updates, SOAP is the wrong transport and Bulk API 2.0 is the answer. Session management also needs care: reuse the session ID across calls rather than logging in per request, or you will trip login rate limits under load.

Failure modes to instrument explicitly:

• INVALID_SESSION_ID — session expiry mid-batch; needs retry-with-reauth logic.
• UNSUPPORTED_API_VERSION / INVALID_OPERATION — the retirement risk, surfacing as hard failures at an arbitrary future date.
• WSDL fetch failure or timeout — availability coupling to Salesforce's metadata endpoint.
• Unmapped SoapFault — lands in generic 500s, invisible to alerting.
• Credential rotation breaking a hardcoded config path.
• PII leakage — full SOAP envelopes in logs are a compliance finding waiting to happen.

Ramp-up. Low for any PHP developer who has touched SOAP: the codebase is small and readable. High for everyone else, and there is no documentation to soften it. The realistic cost is not learning the package — it is learning the Salesforce SOAP surface and the org's specific WSDL, which is a cost you pay regardless of which client you choose.

Recommendation. Do not adopt as a production dependency. Use it as a scoped spike to confirm whether SOAP is required at all, then default to REST/Bulk via a maintained client, and treat this package as documentation of a path previously taken rather than a component to build on.