Json Schema Laravel Package

Product Decisions This Supports

• Schema-as-contract for APIs and events. If the roadmap includes public APIs, webhooks, or internal event buses, JSON Schema is the vendor-neutral way to express "what a valid payload looks like" once and enforce it at the Laravel boundary. This package makes that enforcement a framework concern instead of bespoke Validator::extend code owned by one team.
• Build vs. buy (and "buy" here means free). Writing a spec-compliant JSON Schema validator in-house is a multi-sprint effort with a long tail of edge cases ($ref, allOf/anyOf, format, additionalProperties). Adopting the first-party Illuminate implementation removes that from the backlog at zero license cost.
• Standardizing an internal schema dialect. Teams accumulate a mix of FormRequest rules, manual isset() checks, and ad-hoc DTO hydration. A JSON Schema layer gives PM a defensible "one validation vocabulary" story that spans PHP services and non-PHP consumers (frontends, data pipelines, third-party partners).
• AI/tooling surface area. LLM function-calling and agent tool definitions are expressed in JSON Schema. If the roadmap touches AI features, having schema validation in the same stack that serves the API keeps tool-argument validation and request validation on one code path rather than two.
• Multi-tenant and integration configuration. Tenant-supplied config, partner-submitted manifests, and integration payloads are classic "we can't ship a migration for every customer" problems. Schema validation lets product ship a self-service contract with clear rejection reasons.
• Roadmap scoping signal. The package is versioned and released with the framework, not independently. That means adoption is a decision about staying current on Laravel, not about adding a dependency with its own lifecycle — a materially cheaper commitment to defend in planning.

When to Consider This Package

Adopt when:

• You are already on Laravel and the framework major version you run ships this component; the marginal cost is effectively zero and there is no new vendor or maintainer to vet.
• You need JSON Schema validation inside the Laravel validation pipeline — request validation, form requests, queued job payloads — rather than as a standalone parser in a script.
• You want first-party maintenance, MIT licensing, and no procurement/legal cycle.
• You value release cadence coupling: security fixes arrive with framework patches you are already pulling.

Look elsewhere when:

• You are not on Laravel, or you need this in a plain PHP service, a CLI, or a shared library consumed by non-Laravel code. Take opis/json-schema or swaggest/php-json-schema and keep the coupling explicit.
• You need guaranteed coverage of a specific JSON Schema draft, or features like compiled/cached schemas for high-throughput validation. Verify draft support against your contracts before committing — this is the single most important technical due-diligence item.
• You need schema generation from PHP types/DTOs, or bidirectional OpenAPI round-tripping. This validates; it does not author.
• You need a dependency with an independent release cadence and version pinning decoupled from the framework. A monorepo split package will move when the framework moves.
• Caution on the signals: the 34,984 stars belong to laravel/framework, not to this component, and 0 dependents means there is little public evidence of standalone adoption. Treat both as context, not as validation of this package specifically. Budget for your own spike rather than assuming community-tested behavior.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can enforce API, webhook, and tenant-configuration payload contracts using a component that already ships with our framework — no new vendor, no license fee, no procurement. It replaces hand-written validation code that only one team understands with a declarative, industry-standard schema that partners and non-PHP services can read. The cost is a short integration spike; the return is fewer malformed-payload incidents and faster onboarding of integrations.

For engineering: This is an Illuminate component, versioned and released with the framework you already run, MIT-licensed, maintained by the Laravel core team. No new dependency graph, no extra supply-chain surface, no separate upgrade treadmill. Adopt it behind a thin internal interface — a single PayloadValidator boundary — so if draft coverage or throughput ever falls short, we swap the implementation without touching call sites. That interface is the actual deliverable; the package is the first implementation.

Framing the risk honestly: The star count reflects the framework monorepo and public dependents are near zero, so we should not treat this as a battle-tested standalone library. Mitigate with a two-day spike that exercises our real contracts — nested $ref, oneOf, format handling, and error message quality — plus a fallback plan to a dedicated JSON Schema library if coverage disappoints. Low cost to try, bounded cost to reverse.