Api Client Laravel Package

Product Decisions This Supports

• Build vs. buy for the integration layer. This package is a reference design for "how much structure do we put around outbound HTTP calls?" It answers a recurring PM question: do we hand-roll Http::get() calls scattered across services, or do we invest in a typed client abstraction (resource + endpoint + response objects, hydrators, pagination)? The package is evidence that the abstraction can be built cheaply in PHP — it is small, MIT-licensed, and pattern-oriented rather than feature-heavy.
• Standardising a growing third-party integration surface. If the roadmap includes 3–10 external APIs (payments, CRMs, logistics, data providers), the decision to adopt a convention for how those clients are shaped is a product decision, not just an engineering one. It affects onboarding time, incident blast radius, and how quickly a new partner can be added.
• SDK / public-API strategy. The resource/endpoint/response split maps cleanly onto how we might expose our own API to partners (or consume a partner's). Useful input when scoping "do we publish an SDK?" — it shows the minimum viable shape: typed models, pagination objects, error mapping.
• Roadmap sequencing for integrations. Because the library is thin, it clarifies that the expensive part of an integration is not the HTTP plumbing but the domain modelling (hydration, pagination semantics, rate limits, auth refresh). That reframes integration epics away from "framework work" and toward "mapping work," which is where estimates usually go wrong.
• Tech-debt and consolidation decisions. It provides a defensible target state for teams currently duplicating client code: one client class per vendor, one response envelope, one pagination contract.
• Buy-vs-adopt-vs-fork. At 1 star and 0 dependents, the realistic product decision is not "adopt", but "borrow the pattern" or "evaluate the actively maintained alternative." That is itself a useful decision to have documented.

When to Consider This Package

Consider it as a design reference or a starting scaffold, not as a dependency, when:

• You are on a PHP codebase (Laravel or otherwise) and are about to write your second or third hand-rolled API integration — the point at which ad-hoc Http:: calls start to diverge.
• Your team wants an explicit contract for API clients: a Resource per vendor, an Endpoint per operation, a typed Response, and hydration into domain models rather than arrays.
• You need pagination handled uniformly across multiple providers (page-based, cursor-based) and want a single mental model for it.
• You want a framework-agnostic structure — for example, a client that must be shared between a Laravel app and a queue worker, CLI tool, or a non-Laravel service.
• You are teaching or standardising: the codebase is small enough to read end-to-end and use as an internal convention document.

Look elsewhere if any of the following is true — and for most production contexts, several will be:

• Maintenance and longevity matter. 1 star, 0 dependents, and a single-maintainer lineage is a red flag for anything on a critical path. There is no ecosystem signal that this will be patched for new PHP versions or security issues.
• You want the Laravel-native path. Laravel's Http client plus a thin service class covers the majority of needs; Saloon is the mature, actively maintained Laravel/PHP package for exactly this problem (connectors, requests, auth, retries, caching, testing fakes). Choose Saloon for adoption; use this package as a pattern reference.
• You need batteries-included concerns: OAuth2 token refresh, retry/backoff policies, circuit breaking, request signing, webhook verification, or first-class testing helpers. This library is deliberately thin and leaves those to you.
• You need community support, docs, or hiring signal. You will not find tutorials, Stack Overflow answers, or candidates who have used it.
• Pinning a single-maintainer, near-zero-adoption package creates procurement/security review overhead your organisation isn't prepared to absorb.

Net: reasonable for a spike or an internal pattern write-up; not reasonable as a named production dependency.

How to Pitch It (Stakeholders)

To executives — one paragraph: We evaluated a small open-source PHP library that structures outbound API integrations into consistent, testable pieces. It is well-designed but effectively unmaintained (1 GitHub star, no downstream dependents), so I do not recommend adopting it as a dependency. I do recommend adopting the pattern it demonstrates — one typed client per vendor, one response envelope, one pagination contract — implemented on top of Laravel's HTTP client or the maintained Saloon package. This costs roughly the same as our current ad-hoc approach, reduces the cost of each future integration, and avoids the vendor risk of a single-maintainer library.

To engineering — the substance: Treat somnambulist/api-client as a spec, not a package. It proposes: a client object holding transport config; a Resource per upstream service; an Endpoint per operation encapsulating method, path, and query; a typed response object; and hydration into domain models with pagination as a first-class object. That decomposition is the valuable artefact. Reproduce it with Saloon connectors/requests (or Laravel Http + invokable request classes), keep hydration explicit, and add the operational concerns the library omits: retries, timeouts, auth refresh, rate-limit handling, and Http::fake()-based contract tests. Document it as an internal convention so the third integration is cheaper than the first.

To security/procurement: No new third-party dependency proposed. The pattern uses first-party or already-vetted packages. If we later want the library itself, flag that it is single-maintainer with no downstream adoption and should go through standard open-source risk review — but note that our current recommendation makes that request unnecessary.