Product Decisions This Supports
- Build vs. buy vs. adopt for CRM integration. This package is a data point on the "adopt" branch of that decision, and a negative one: a thin, single-maintainer wrapper around the Salesforce SOAP API with no dependents and no release since 2015 is not a foundation for a revenue-adjacent integration. The decision it most cleanly supports is stop evaluating community SOAP wrappers and standardize on a maintained REST/Bulk API client.
- API strategy on the roadmap. Salesforce has spent a decade steering integrators toward REST, Composite, Bulk API 2.0, and Platform Events; SOAP remains supported but is the legacy path with older API versions retired on a schedule. If a roadmap item says "Salesforce integration," this package implicitly commits the team to the legacy surface, which constrains future features (event-driven sync, large data loads, modern auth flows) before work begins.
- Total cost of ownership modelling for OSS dependencies. Zero license cost, effectively infinite maintenance cost: no security patches, no PHP 8 compatibility guarantees, no upstream to escalate to, and a knowledge base of one repository with one star. Useful as a concrete example when justifying a dependency-vetting policy or an internal "supported dependencies" list.
- Risk register / legacy audit input. If any existing service already depends on it, that's a finding: pinned Salesforce API version, PHP SOAP extension requirements, and no migration path documented by the author. Feeds a remediation ticket rather than a greenfield decision.
- Integration ownership and on-call. SOAP faults, WSDL drift, and Salesforce-side version retirements become your team's incident surface. This shapes staffing and support-tier decisions for the integration, and argues for owning the client code outright if SOAP truly must be spoken.
- Buy signal for managed iPaaS. Where the business need is "sync objects between our app and Salesforce," the existence of only fragile open-source options strengthens the case for evaluating a commercial connector or iPaaS rather than hand-rolling.
When to Consider This Package
Consider it only in a narrow, defensive scenario:
- A PHP application already ships it in production, the integration is stable, and the Salesforce API version in use has not yet been retired. Here the decision is "fork and vendor," not "adopt" — pin the dependency, read the code end to end, add your own tests around the calls you actually make, and put a migration date on the calendar.
- You need a small, readable reference implementation of Salesforce SOAP session handling (login, session header, basic CRUD) to understand the protocol before writing your own thin client. Read it as documentation; don't depend on it.
- Your organization has an explicit constraint requiring SOAP (a legacy enterprise integration layer, or a Salesforce object/operation genuinely unreachable via REST), and you have PHP/SOAP expertise in-house to own the code.
Look elsewhere in essentially every other case:
- New integrations. Use a maintained client —
omniphx/forcedotcom for a PHP Salesforce SDK, or an HTTP client such as Saloon or Laravel's HTTP client against the REST API directly. For bulk work, target Bulk API 2.0.
- Modern auth. OAuth 2.0 JWT bearer flow, connected apps, and refresh-token handling are table stakes; a 2015 SOAP wrapper will not model them.
- Any team without in-house SOAP/WSDL competence. Debugging faults and WSDL changes without upstream support is a poor use of engineering time.
- Laravel-native expectations. No service provider, no facade, no config publishing, no queue/retry integration, no test helpers. You will write all the glue, which erases the only thing the package saves you.
- Anything with a security or compliance review. An unmaintained dependency in a path that handles customer data will not clear review, and shouldn't.
How to Pitch It (Stakeholders)
To executives: We evaluated a free, open-source PHP client for Salesforce. It is MIT-licensed and costs nothing to download, but it has had no release since 2015, no community around it (one star, zero dependent projects), and no author actively maintaining it. Free in license, expensive in ownership: no security patches, no compatibility guarantees with current PHP or Salesforce API versions, and no one to call when it breaks. Because this sits on the path that moves customer and revenue data, I recommend we do not adopt it. The recommended alternative — a maintained PHP Salesforce client or direct REST/Bulk API integration — costs a small amount of engineering time and removes a standing operational and audit risk. Net: slightly higher upfront build, materially lower lifetime cost and risk.
To engineering: It's a thin SOAP wrapper from the PHP 5 era, effectively unmaintained, with no tests, no CI, no Laravel integration, and no modern auth support. It buys us maybe a day of boilerplate and costs us ownership of a protocol surface we don't want. Proposal: integrate against the Salesforce REST and Bulk APIs using a maintained client or a small in-house client built on our existing HTTP stack, with token refresh handled explicitly and integration tests against a sandbox org. If we are forced into SOAP by an existing constraint, we write and own a minimal client with generated WSDL stubs and real tests — and we budget for it as first-class code, not a dependency. Either way, flag any existing usage of this package now so we can scope a migration rather than discover it during an API version retirement.