Salesforce Client Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for CRM plumbing. This is a candidate shortcut for the non-differentiating 80% of a Salesforce integration: OAuth/JWT bearer auth, token refresh, REST CRUD, and error mapping. If it clears diligence, it moves effort from "wire up auth" to "model the customer data."
• Roadmap scoping for a Salesforce surface. Useful for sizing discovery work on lead/contact sync, case mirroring, entitlement or asset lookups, and read-only enrichment of our own records. It is a seed for that work, not a finished connector.
• Architecture direction — and a caveat worth surfacing early. Despite being framed as a Laravel/PHP option, this is a Symfony bundle, not a Laravel package. It expects Symfony's service container and kernel. For a Laravel shop the realistic value is as a reference implementation of the Salesforce auth handshake and REST client, not a composer require dependency. That distinction should be settled before it reaches a sprint.
• Integration-shape decisions it informs: one-way vs. bi-directional sync, data ownership and system-of-record, polling vs. event-driven (Platform Events / Change Data Capture), and whether we need Bulk API 2.0 for volume — the bundle's surface area here is worth verifying.
• Vendor-risk posture. Zero stars, zero dependents, a single maintainer, and a January 2025 release means adopting it is effectively deciding to own a fork. That is a legitimate call for internal tooling; it is a poor call for anything with an SLA attached.

When to Consider This Package

Reasonable to evaluate when:

• We are already a Symfony shop and want a small, MIT-licensed starting point rather than a blank file.
• The integration is internal-facing, read-heavy, and single-tenant (one Salesforce org, modest request volume).
• The team is comfortable forking and maintaining ~a few hundred lines of glue, and can absorb API-version churn on its own schedule.
• We want a worked example of the JWT bearer flow to validate our own design against.

Look elsewhere when:

• We are on Laravel — use a maintained Laravel-native SDK, or build on Saloon/Guzzle with an explicit auth layer. Cleaner than bending a Symfony bundle.
• Volume, retries, and ordering matter: evaluate an iPaaS (MuleSoft, Boomi) or Salesforce-side tooling (Heroku Connect, Platform Events) instead of a hand-rolled client.
• We need Bulk API 2.0, composite graphs, or streaming — confirm support before committing; a thin REST wrapper usually stops short.
• Regulated data or a support contract is in scope. An unaudited, single-maintainer dependency will not survive a security review; expect to vendor it and own the patch cadence.
• Salesforce API version pinning is a blocker — Salesforce retires API versions on a rolling ~3-year cycle, so a client that hard-codes a version needs a configurable override.

Diligence before any pilot: auth flow coverage (JWT vs. web-server OAuth), token/credential storage, configurable API version, test/mocking story for CI, and a read of the actual commit history behind that single release.

How to Pitch It (Stakeholders)

To executives: There is a free, MIT-licensed PHP starting point for talking to Salesforce. It is genuinely small and genuinely unproven — zero community adoption, one maintainer. The right framing is "cheap head start we will own," not "vendor we can lean on." Recommendation: fund a short timeboxed spike to validate it against our actual objects and volumes, with a decision gate at the end — adopt as a fork, or fall back to a native build. Either way the cost is small and the learning is real; the risk is treating it as a supported platform.

To engineering: Treat this as a reference implementation, not a dependency — especially if we are on Laravel, where a Symfony bundle doesn't drop in. Lift the auth and client patterns, keep the Salesforce API version configurable, and assume we own the fork and its patch cadence from day one.