Laravel Response Api Laravel Package

Product Decisions This Supports

• Build vs. buy for API plumbing. This package owns a commodity concern — consistent JSON response envelopes (success/error shape, status codes for created(), updated(), destroyed(), pagination payloads). Adopting it lets the team spend roadmap capacity on domain features instead of re-implementing response helpers in every controller.
• API contract standardization. Decides whether to converge all existing endpoints on one response shape. Relevant to roadmap items like public/partner API launch, mobile client SDKs, versioned API (/v2), and OpenAPI documentation — every consumer downstream depends on a stable envelope.
• Client-facing reliability. Uniform pagination metadata and correct HTTP semantics (201 on create, 204 on delete) reduce client-side special-casing and integration bugs — a measurable support-cost lever for partner-facing products.
• Estimating the "API consistency" epic. This release is maintenance-only (no new features, no breaking changes), but it materially de-risks the estimate: 100% test coverage and PHPStan level-max clean means low ongoing maintenance cost and low probability of the dependency becoming a schedule risk.
• Tooling policy alignment. The upgrade to PHPStan ^2.0 / Rector ^2.0 confirms the package keeps pace with the static-analysis stack the team is standardizing on — a factor in dependency-approval decisions.

When to Consider This Package

Adopt when:

• You expose JSON APIs from Laravel and controllers currently hand-assemble response arrays or duplicate status-code logic.
• You want consistent pagination envelopes and create/update/delete semantics with near-zero boilerplate.
• Your CI enforces static analysis (PHPStan/Larastan at high levels) — the 2.0.1 release explicitly targets PHPStan max and adds coverage tooling, so it will not fight your pipeline.
• Your PHP/Laravel versions fall inside the package's Composer constraints — verify before committing (this release raises dev-tooling floors to PHPStan/Rector 2.x; confirm runtime support matches your matrix).
• The team is small and the cost of owning a bespoke response layer outweighs the cost of a thin external dependency.

Look elsewhere when:

• You need a full spec-driven contract (JSON:API, HAL, OpenAPI-first codegen) rather than a conventional envelope.
• You already have a mature internal response layer, or your existing client contracts are locked to a different shape — the migration cost will exceed the benefit.
• You require long-term vendor support/SLAs; this is a single-maintainer-style utility, so wrap it behind your own interface to contain lock-in.
• You need response concerns the package doesn't cover (content negotiation, GraphQL, streaming) — don't stretch it beyond its scope.

How to Pitch It (Stakeholders)

For executives: This is a small, low-risk utility dependency that standardizes how our API talks to clients. The 2.0.1 release is maintenance-only — no new features, no breaking changes — but it ships with 100% test coverage and passes the strictest static analysis settings our engineering standard uses. Translation: it reduces the engineering days we'd otherwise spend rebuilding response plumbing, and it lowers the risk of inconsistent API behavior surfacing as partner integration bugs.

For engineering: Small surface area (facade, builder, service provider), now at 100% coverage including created(), updated(), destroyed() and pagination paths, with PHPStan max errors resolved and Rector/PHPStan upgraded to 2.x. Recommended adoption path: wrap it in a thin internal adapter (our own ApiResponder interface) so controllers depend on our abstraction, not the package — this keeps the upgrade path open and makes a future swap a one-file change.

Ask: Approve adoption as a pilot on one new endpoint, with the adapter in place and a one-sprint check-in on developer ergonomics and client feedback.