Sdk Kernel Laravel Package

Product Decisions This Supports

• Build vs. buy for the SDK layer. sdk-kernel is plumbing, not a product: auth/token handling, request signing, HTTP dispatch, response/error mapping, middleware pipelines, config objects. The decision it informs is whether to standardize that plumbing once and reuse it across every SDK you ship, rather than re-solving it per integration.
• Roadmap sequencing for integrations. If your roadmap contains multiple API connectors (payments, messaging, logistics, cloud, partner APIs), a shared kernel turns "each integration is a project" into "each integration is a configuration plus a mapper." That changes how many connectors you can credibly commit to per quarter.
• Developer-experience as a feature. For platform/API products, the SDK is the onboarding surface. A consistent kernel means consistent pagination, retries, error types, and auth ergonomics across every language client's PHP counterpart — a support-cost and time-to-first-success decision.
• Use cases it fits: first-party PHP SDKs for your own REST API, a portfolio of vendor SDKs behind one internal interface, and adapter layers where you need uniform behavior (backoff, rate limiting, token refresh) regardless of which vendor you're calling.
• What it does not decide: product scope, endpoint design, or vendor selection. It's an accelerator for teams already committed to shipping PHP clients.

When to Consider This Package

Consider it when:

• You will ship more than one PHP SDK or integration, and you want one opinion on auth, signing, retries, pagination, and error semantics instead of N divergent ones.
• Your team is PHP/Laravel-native and values convention over a heavier framework's opinions.
• You have engineering capacity to own the code. MIT license, small surface area, readable internals — forkable and vendorable.
• You're willing to run a timeboxed spike (days, not weeks) and an internal code review before it touches a critical path.

Look elsewhere when:

• It's a single integration — use Laravel's HTTP client or Saloon directly; a kernel is overhead at N=1.
• You need a maintained, battle-tested toolkit with community support, security advisories, and a release cadence — Saloon, Guzzle, or the vendor's official SDK are the safer defaults.
• The work sits on a long-lived critical path where supply-chain risk, abandonment, or an unpatched CVE is unacceptable.
• You have no appetite to fork and maintain it — with 0 stars and 0 dependents, there is no support net.

How to Pitch It (Stakeholders)

Executives: This is infrastructure that lowers the marginal cost of every integration and SDK we ship. Instead of each connector re-implementing auth, retries, and error handling, we standardize once and reuse. The payoff is throughput on the roadmap and a more consistent developer experience for partners — measurable as time-to-first-successful-call and integration cycle time.

Engineering: A thin, MIT-licensed kernel that isolates HTTP transport, signing, token lifecycle, and error mapping behind a convention-driven API, so product code stays focused on the domain model. It's small enough to audit in an afternoon and fork if needed; it slots naturally into a Laravel codebase without imposing a runtime.

The honest caveat, stated up front: this is an unproven package — zero stars, zero dependents, no community or security track record. Pitch it as a seed for an internal pattern we own, not as a strategic dependency. Recommended path: run a short spike, audit the internals, then vendor or fork it and treat it as first-party code with our own tests and release process. If we're not prepared to own it, we shouldn't adopt it.