Two Tility Laravel Package

Product Decisions This Supports

• Adopt vs. build: Informs whether to standardize outbound third-party API calls on this package's BaseApiClient rather than maintaining bespoke HTTP wrappers in each Laravel service.
• Reliability roadmap: The 1.0.2 fix makes configured retries functional for connection failures and HTTP 429s on Laravel 12/13 — repositioning the package from "retry config that silently no-ops" to a credible resilience layer.
• Feature prioritization: Signals that retry/backoff and rate-limit handling are first-class concerns; useful when scoping integration-hardening work (timeouts, idempotency, circuit breaking) against what the package already covers.
• Risk audit: Teams already on 1.0.0/1.0.1 may have shipped with a false sense of resilience — previously, retries never matched due to a callback signature mismatch. This release is a prompt to re-verify failure-handling assumptions and incident runbooks.
• Use cases: Services integrating rate-limited or flaky external APIs (payments, CRMs, messaging, data providers), especially multi-tenant products where one tenant's upstream throttling shouldn't surface as user-facing errors.

When to Consider This Package

Consider it when:

• You operate multiple Laravel services calling external APIs and want one consistent retry/timeout convention instead of per-team implementations.
• Your integrations encounter 429 responses or transient connection failures, and you want that handled at the client base class rather than in every call site.
• You are on Laravel 12/13, which is the target of the 1.0.2 fix.
• You want a thin, framework-idiomatic base class you can extend, not a full API gateway or SDK generator.

Look elsewhere when:

• You have a single, simple integration — Laravel's built-in Http::retry() covers it without another dependency.
• You need mature observability, metrics, or circuit-breaking; this package's scope appears limited to client configuration and retries.
• You require a proven track record — at 1.0.2 with a retry defect only now corrected, adoption should be piloted rather than assumed safe at scale.
• Your upstream APIs require complex auth flows, pagination, or schema validation beyond what a base client provides.

How to Pitch It (Stakeholders)

For executives: A small, low-cost dependency that hardens our integrations against transient API failures and rate limiting, reducing avoidable incidents and support load. It is early-stage, so we recommend a bounded pilot before broad rollout.

For engineering: The package provides a BaseApiClient with configurable retries. Version 1.0.2 fixes a real defect — the retry callback used the wrong signature and never matched, so retries did not fire for connection failures or 429s on Laravel 12/13. Anyone who adopted an earlier version must upgrade and re-test, because prior resilience behavior was effectively inert. Note the behavioral change: retries now actually execute, which can increase request volume against upstream providers — confirm rate-limit budgets and idempotency before enabling in production. Recommended path: pilot on one non-critical integration, add tests asserting retry attempts on connection error and 429, then standardize.