Force.com Toolkit For Php Laravel Package

Technical Evaluation

Architecture fit. This is not a Laravel package. developerforce/force.com-toolkit-for-php is a plain PHP SOAP client for Salesforce's Partner and Enterprise WSDLs, published before Laravel auto-discovery and service-provider conventions were standard. It will not register itself in the container, ships no config, no facade, and no Laravel-facing abstractions. Architecturally it fits only as a low-level transport adapter wrapped behind our own gateway interface; it should never be called directly from controllers or jobs.

Integration feasibility. Installable via Composer and technically callable from Laravel today, but it requires ext-soap and ext-openssl, a WSDL source (static Partner WSDL file or per-org Enterprise WSDL), and a manual credential/login flow. The typical pattern is a SOAP login() to obtain a session ID and instance URL, then either continue over SOAP or hand the session to REST callouts. Wrapping it in a service provider, config file, and a small repository layer is a few days of work — not a blocker, but it is bespoke code we own.

Technical risk. High, and mostly non-technical in origin:

• Archived since 2015. No security patches, no PHP 8 compatibility work, no dependency updates. PHP 5-era constructs and abandoned transitive dependencies are likely to break on modern PHP runtimes.
• Salesforce API version retirement. The bundled WSDL and generated stubs target an old API version. Salesforce retires API versions on a rolling basis, so this becomes a scheduled hard failure, not a gradual degradation.
• License is NOASSERTION. Legal review is mandatory before shipping to production; the actual terms may be BSD-style but cannot be assumed.
• SOAP-first design. Salesforce's strategic direction is REST/GraphQL/Bulk API 2.0; SOAP remains supported but is not where new capability lands.

Key questions.

1. Which Salesforce API version does the pinned WSDL target, and when does Salesforce retire it?
2. Do we actually need SOAP (Partner WSDL metadata discovery, describeSObjects), or would OAuth + REST via Laravel's HTTP client cover 100% of our use cases?
3. What is the license, confirmed by legal rather than inferred?
4. What PHP version must we support, and has anyone verified the code path under it?
5. Who owns the fork when it breaks — is there a named maintainer and budget?
6. Are there existing consumers in our codebase, or is this greenfield?

Bottom line. Viable only as a short-lived bridge or as a fork we explicitly own. For new work, the opportunity score (12.33) and archived status argue against adoption.

Integration Approach

Stack fit. Treat it as an implementation detail behind a SalesforceClient interface with methods expressed in our domain terms (upsertAccount, queryContacts), not SOAP verbs. Bind the implementation in a service provider, drive credentials from config/services.php and encrypted env vars, and expose a thin facade only if multiple call sites need it. Cache the session ID and instance URL in the cache store with a TTL below Salesforce's session timeout to avoid a SOAP login on every request.

Migration path. Run a two-track spike:

• Track A (preferred): Laravel HTTP client + OAuth 2.0 JWT bearer flow against Salesforce REST. No third-party dependency, native retries, native logging, no WSDL parsing, current API version by construction.
• Track B: This toolkit behind the same interface, to confirm whether SOAP-only features (metadata describe, certain composite operations) are genuinely required.

If Track A covers the use cases, do not adopt. If Track B wins on a narrow feature, adopt it behind the interface so it can be swapped without touching call sites.

Compatibility. Verify Composer resolution against our PHP constraint, confirm ext-soap is present in every runtime including queue workers and CI, and check TLS/proxy behavior for outbound calls. Enterprise WSDL files are large and org-specific — they should not be committed per environment; prefer the Partner WSDL or generate at deploy. Static WSDL parsing also has a cold-start cost worth measuring.

Sequencing.

1. License and security review; confirm PHP runtime compatibility in a scratch container.
2. Interface definition and adapter skeleton (one day, decoupled from vendor choice).
3. Parallel spike: REST path vs. toolkit path against a sandbox org.
4. Decision gate with explicit criteria — feature coverage, effort, ongoing ownership cost.
5. If adopted: implement adapter, add contract tests against sandbox, document the API version and its retirement date in the repo.
6. Roll out read paths first, then writes, then bulk operations.
7. Schedule the replacement review at the API retirement date, not "someday."

Operational Impact

Maintenance. Effectively fork-and-own. Upstream is archived, so every fix is ours: PHP upgrades, dependency drift, Salesforce API changes, TLS/certificate rotations. Budget a standing fraction of an engineer and put the package on the same review cadence as first-party code. Pin the version explicitly and vendor or mirror it if Packagist availability is a concern.

Support. Community-only. No vendor, no SLA, no security advisories. Incident response depends on our own debugging of SOAP faults, which are verbose but poorly documented. Expect slow diagnosis for auth and session issues.

Scaling. Two constraints dominate: Salesforce API call limits (daily and concurrent) and the cost of SOAP login. Session reuse and request batching are mandatory, not optional. Large WSDL parsing per process affects cold starts under autoscaling; warm it or cache the parsed metadata. SOAP payloads are heavier than REST equivalents, which matters for bulk sync jobs.

Failure modes.

• API version retirement — hard, scheduled, org-wide breakage. The single largest risk.
• Session expiry mid-job — long-running queue workers hold stale session IDs; requires retry-with-reauth logic.
• PHP runtime upgrade — silent fatal errors in archived code with no upstream fix.
• SOAP faults surfacing as opaque exceptions — error handling must translate fault codes into actionable domain errors and log the raw envelope.
• Credential rotation — manual config changes with no discovery mechanism.
• TLS/proxy changes — outbound connectivity failures that look like auth failures.

Ramp-up. Low to make a first API call, moderate to high to operate safely. The library itself is small; the real learning curve is the Salesforce object model, governor limits, and auth semantics. Plan a one-to-two week spike including sandbox setup, and ensure at least one engineer has Salesforce platform familiarity before this reaches production. Documentation for this package is thin and largely external, so institutional knowledge must be written down rather than assumed.