Product Decisions This Supports
- Build vs. borrow for the support integration. This package is the "borrow" option: it removes the cost of hand-rolling an HTTP client for Snappy (the customer-support/ticketing platform) without committing to a heavyweight vendor SDK. The decision it unblocks is whether support data becomes a first-class surface in the product this quarter or stays a link-out.
- Roadmap sequencing for support-adjacent features. If adopted, these shift from weeks to days of work: creating tickets from in-app forms, syncing contacts/accounts on signup, surfacing open-conversation status on the admin account page, and reacting to Snappy webhooks (ticket created/closed) inside queued Laravel jobs.
- A unified customer view. Read/write access to contacts and tickets is the prerequisite for showing "open support conversations" next to account data — a common CSM and retention ask that needs an explicit PM call on scope and acceptable data freshness.
- Lock-in and exit-cost planning. The package is thin and MIT-licensed, so the real lock-in is the Snappy API contract, not this code. That supports a "commit to the vendor, wrap the client" strategy rather than treating the SDK as strategic infrastructure.
- Buy-vs-build for the glue layer. The credible alternative is a ~200-line internal adapter over Laravel's
Http client or Saloon. The PM decision is whether the saved effort outweighs owning a dependency with 9 stars and 0 dependents — not whether the SDK is "good."
- Diligence flag before any of the above: confirm this is the Snappy customer-support API and not the unrelated wkhtmltopdf/PDF ecosystem (
knplabs/knp-snappy, barryvdh/laravel-snappy). The name collides; a wrong assumption here costs a sprint.
When to Consider This Package
Adopt, or spike, when:
- Snappy is already the support system of record — the vendor decision is made and this is only the transport layer.
- Scope is a handful of endpoints (tickets, contacts, conversations) plus a webhook receiver; we don't need exhaustive API coverage.
- The team is Laravel-standard and comfortable pinning a version and isolating the SDK behind our own interface (
SnappyClient contract bound in the container).
- Speed matters more than dependency prestige, and security review accepts a small, auditable MIT package locked to a fixed commit or version.
- We can absorb the maintenance risk: wrap it,
Http::fake() it in tests, and keep a documented fallback to a direct HTTP adapter.
Look elsewhere when:
- Maturity signals matter to the org. 9 stars, 0 dependents, no visible community, and a low composite score mean effectively single-maintainer risk, no Stack Overflow corpus, and no guarantee of tracking API changes. Treat it as sample code you happen to install, not a supported product.
- Coverage is incomplete or stale. If the endpoints we need aren't there, a Saloon connector gives typed requests, retries, auth, and first-class testing for comparable effort.
- Requirements exceed a thin client: two-way sync at volume, rate-limit/backoff handling, idempotency, retry queues, observability, or multi-tenant credential management. That's an internal adapter, not an SDK.
- The vendor isn't chosen yet. Never let a 9-star package tilt a helpdesk/platform selection; evaluate Snappy on product fit, pricing, and API quality, and treat client availability as a footnote.
- Procurement/security requires maintained dependencies with release cadence and vulnerability history — this package likely won't clear that bar without a named internal owner.
How to Pitch It (Stakeholders)
To executives (one paragraph): We need to connect our product to Snappy, our support platform. This is a small, MIT-licensed PHP client that lets us ship that connection in days rather than weeks at effectively zero cost. It is plumbing, not a strategic bet — the real commitment is the Snappy vendor relationship, and because the package is thin we can replace it with our own adapter without re-architecting. Approving a short spike validates coverage and auth before we take on any commitment.
To engineering: Thin wrapper, isolated behind an internal interface, version-pinned, covered by Http::fake() tests, with a known fallback (Saloon or Laravel's Http client) if it goes stale. We own the retries, queueing, throttling, and webhook handling — assume the SDK does none of that, and never call it synchronously in a user-facing request path.
To finance/legal: No license cost (MIT), negligible switching cost, reversible decision. The risk is maintenance, not money; mitigated by roughly 1–2 days of wrapping work and a quarterly review trigger.
The ask: A 1–2 day spike to confirm API coverage for tickets/contacts/webhooks, the auth flow, and error behavior — then a go/no-go on adoption versus a hand-rolled adapter.