Laravel Request Docs Laravel Package

Product Decisions This Supports

• Build vs. buy for API documentation: this package generates request/response docs directly from your Laravel routes and controllers, so the decision becomes "adopt an in-app generator" rather than "staff a technical writer or buy a docs SaaS." Worth weighing against hosted portals and OpenAPI-first tooling.
• Documentation drift as a roadmap risk: docs are derived from the codebase, so they track refactors by default. This supports decisions to keep API docs current without adding a manual sync step to every sprint.
• Laravel upgrade planning: v2.44 adds Laravel 13.x compatibility. That removes this package as a blocker on the framework upgrade path and is a concrete input to sequencing the Laravel 13 migration.
• Internal API catalog / onboarding: useful for surfacing an inventory of existing endpoints — supports decisions about deprecating, consolidating, or exposing APIs, and shortens onboarding for new engineers, QA, and support.
• Vendor/maintenance risk assessment: a same-day compatibility release signals an actively maintained dependency. That's a factor in dependency-approval and long-term support decisions.
• Support and QA enablement: an interactive in-app reference (execute requests from the docs UI) can reduce back-and-forth between support, QA, and engineering on request shapes.

When to Consider This Package

Adopt when:

• You have a Laravel application with a substantial, JSON/REST-style API surface and no reliable documentation today.
• You want docs generated from source with near-zero ongoing effort and no external SaaS dependency or data leaving your infrastructure.
• You're comfortable scoping it to local/staging and gating it behind auth/middleware — it is a developer tool, not a public docs site.
• You're planning or evaluating a Laravel 13 upgrade and need your dev-tooling dependencies to be compatible.
• Internal consumers (mobile, frontend, partners) need a browsable endpoint reference more than a curated narrative.

Look elsewhere when:

• The docs are customer-facing and need information architecture, versioning, guides, and branding — use a dedicated docs platform, and consider OpenAPI + Redoc/Scalar as the delivery layer.
• You operate contract-first: schema design should precede and constrain implementation (OpenAPI-first, Scribe, or Scramble with an exported spec).
• You're in a restricted or compliance-heavy environment where any route that introspects and echoes request/response data is unacceptable, even in non-production.
• Your API is GraphQL, gRPC, or largely non-Laravel — the value proposition collapses.
• Documentation quality depends on human-authored narrative and examples rather than route introspection.

How to Pitch It (Stakeholders)

To executives: We have an API documentation gap that costs us onboarding time and support cycles. This package closes it by generating docs directly from our Laravel code — no new headcount, no SaaS subscription, no data leaving our infrastructure. The v2.44 release confirms it's actively maintained and already supports Laravel 13, so it doesn't create a future upgrade liability. Recommended scope: internal/staging only, behind access control.

To engineering: One dependency, auto-discovers your routes, renders an interactive reference with request/response samples. Zero annotation burden for basic coverage, and it won't block the Laravel 13 upgrade. Trade-off to accept explicitly: it's introspection-based rather than contract-first, so it documents what the code does, not what the API promises — pair it with an OpenAPI export if we ever need a formal contract or public-facing docs.

Caveats to state up front: treat it as a dev-only tool, gate it behind auth and non-production environments, and don't let it become the canonical source of truth for external API contracts.