Laravel Json Response Laravel Package

Product Decisions This Supports

• API-only posture: whether the product commits to "every client is a machine" — SPA, mobile, partner integrations — and therefore every response, including framework-generated 404/405/419/500 pages and validation errors, must be JSON. If yes, this is table-stakes hygiene, not a feature.
• Build vs. buy for cross-cutting plumbing: forcing JSON is a ~15-line middleware (set Accept: application/json before routing, or a ForceJsonResponse middleware). The PM decision remains "build in-house," not "adopt a dependency" — a Laravel 13 compatibility PR does not change the size of the code we would be replacing.
• Error-contract reliability: if support tickets show clients choking on HTML error pages (CSRF 419, 500 debug pages, 405s from webhook providers), a forcing middleware is a cheap one-sprint fix that removes a whole class of integration bugs.
• Roadmap enabler, not roadmap item: deterministic JSON output is a prerequisite for versioned error envelopes, RFC 9457 problem+json, and generated client SDKs — but it does not belong on a roadmap as its own line.
• Explicitly does not support: content negotiation (serving HTML and JSON from the same route), API versioning strategy, or error taxonomy design. Those need a richer solution than a header-forcing middleware.

When to Consider This Package

Consider the pattern when:

• The app is API-only, or the api route group must never leak HTML to a client.
• Clients are sloppy about Accept headers — mobile HTTP libraries, curl scripts, third-party webhooks — and you want deterministic JSON regardless.
• You want a one-line test guarantee: every response in the api group is application/json.

Consider this package still essentially never:

• Maintenance signal is "alive, not healthy." Release 3.2.0 adds an explicit Laravel 13 compatibility PR and otherwise contains only bot commits (license year, banner image, README preview). That is a single community contribution, not a maintained support policy, and it directly contradicts the earlier "archived / unmaintained" read — so treat the project as intermittently maintained with no commitment, not dead. Either way, it carries no security-patch SLA and no forward-compatibility guarantee beyond the last volunteer PR.
• Adoption remains effectively zero: ~12 stars, no dependents, low opportunity score. One Laravel 13 PR does not create ecosystem validation or community fork pressure.
• The composer.json platform constraint should be verified before assuming 3.2.0 covers your Laravel version; a compatibility bump is not the same as a tested support matrix.
• Look elsewhere or build in-house if you need: problem+json error bodies, per-endpoint error codes, localized error messages, dual HTML/JSON rendering, or normalization of status codes and exception payloads.
• If a single low-adoption repo is the only guarantee of JSON output, that is a supply-chain liability purchased for two lines of code.

How to Pitch It (Stakeholders)

To executives: The capability is worth having — every API client gets consistent JSON errors instead of HTML pages, which reduces integration support load. But we should not take a dependency here. Release 3.2.0 shows the project is not abandoned (a contributor added Laravel 13 support), which is a genuinely better signal than "archived," yet it is still a near-zero-adoption repo with no support commitment and nothing in the release beyond a compatibility bump and bot housekeeping. This remains a weekend-sized middleware we own: adopting it trades a small convenience for a permanent maintenance question mark on our response path, and buys us no vendor relationship or roadmap influence.

To engineering: Implement a ForceJsonResponse middleware that sets Accept: application/json on api-group requests, register it on the api group, and add two feature tests: a 404 on an api route returns JSON, and a validation failure returns JSON. That is functionally equivalent to this package for our needs, keeps us in control of the error envelope, and avoids pinning a Laravel version to a repo maintained by sporadic volunteer PRs. Note that 3.2.0's Laravel 13 claim should be treated as "not broken on 13" rather than "supported on 13." Revisit only if requirements grow to full content negotiation — and in that case choose a maintained library, not this one.