Laravel Json Schema Request Laravel Package

Product Decisions This Supports

• API contract strategy (spec-first vs. code-first): the package lets a Laravel FormRequest validate the raw request payload against a JSON Schema document rather than hand-written rule arrays. That is a lever for deciding whether JSON Schema / OpenAPI artifacts become the source of truth for your API surface, or stay as documentation that drifts from the code.
• Build vs. buy on request validation: replaces a bespoke "validate against our contract file" layer with a maintained package. Compare the cost of owning that glue (schema loading, $ref resolution, error mapping, version tracking) against a pinned dependency.
• Roadmap: public/partner API exposure. Strict schema validation is most valuable where consumers are outside your deploy cadence. If public API or SDK work is on the roadmap, an early decision to standardise on JSON Schema pays off later (client generation, contract tests, cross-language validation in non-PHP services).
• Cross-team contract ownership. If frontend, mobile, or a separate service team already authors schemas, this package lets Laravel consume the same artifact instead of duplicating rules — a governance decision about who owns the contract.
• Platform version planning (this release). v4.0.0 drops Laravel 11 and adds Laravel 13. Any product still on Laravel 11 is effectively frozen at v3.2.0 and accrues upgrade debt. Treat this as an input to the framework-upgrade roadmap, not a validation detail.
• Public error-contract decision (this release). v4.0.0 changes failed authorization to return 403. If clients branch on status codes (401 vs. 403 vs. 422), this is a customer-visible contract change that needs a docs/versioning call before rollout.

When to Consider This Package

Adopt when:

• You already maintain — or are willing to maintain — JSON Schema or OpenAPI documents, and want runtime validation to match them exactly.
• Your API has consumers you don't control (partners, mobile apps, other services) where contract drift is expensive.
• Validation needs exceed Laravel's rule set: oneOf/anyOf, $ref reuse, deeply conditional payloads, or schema shapes shared with a non-PHP service.
• You want contract tests and runtime validation to read from the same file.
• You are on Laravel 12 or 13 (v4.0.0 requirement), or can plan the upgrade.

Look elsewhere when:

• The product is server-rendered (Blade/Inertia/Livewire) with simple, local forms — native FormRequest rules and Laravel's default validation responses are cheaper and better documented.
• You have no schema artifacts and no appetite to create them; the package adds a second validation vocabulary for the team to learn.
• You need Laravel's conventional 422 + errors bag UX out of the box and don't want to own the mapping from schema violations to your error format.
• You are staying on Laravel 11. v3.2.0 remains available but is now off the mainline; that is a supported-but-frozen position you should accept deliberately.
• The validation logic is genuinely one or two endpoints — a dependency plus a schema pipeline is overkill.

How to Pitch It (Stakeholders)

For executives: this is a small, low-cost dependency that lets our API enforce the same contract document we publish to partners and client teams. The business value is fewer integration defects and less time reconciling "what the docs say" against "what the API accepts" — a recurring cost in every partner integration. It is not a new platform; it is a validation layer inside Laravel. The one governance ask: it ties our framework upgrade cadence to the package's release cadence (v4 requires Laravel 12+, and drops Laravel 11), so it belongs in upgrade planning rather than being adopted silently.

For engineering: a FormRequest subclass that validates the request body against a JSON Schema instead of an inline rules array, giving us $ref reuse, composition keywords, and a single contract artifact shared with other services. It is a thin layer over Laravel's existing request lifecycle — no new runtime, no new infrastructure. Two caveats to plan for in v4.0.0: Laravel 11 support is removed (pin v3.2.0 if we're not upgrading), and failed authorization now returns 403 instead of the previous status — audit client-side handling and our API error documentation before we ship the bump. Treat the major version as a coordinated upgrade, not a routine composer update.