Api Platform Filter Validator Laravel Package

Product Decisions This Supports

Build vs. wait vs. patch. The package's raison d'être is a single unmerged upstream PR (api-platform/core#1723). That makes it a timeline decision, not an architecture decision: do we (a) block the filtering feature on core, (b) write our own validation layer, or (c) adopt this as a thin, time-boxed shim and schedule the removal. Framing it as (c) with an explicit exit criterion is usually the honest choice.

Whether to ship rich filtering to untrusted clients at all. Filter parameters are user input, and unvalidated input flows into query building. Until values are constrained, you're implicitly deciding to accept 500s, driver-level errors, and potentially expensive or malformed queries from anyone who can hit the endpoint. This package lets you say "yes, we can expose filters" without that caveat.

Roadmap sequencing and scope of the validation work. It tells you how much of the validation story you still own: constraint definitions per filter (types, ranges, enums, formats), error-response shape consistency with the rest of the API, and whether validation failures return 400s with useful messages or the platform's default error envelope.

Risk posture / security review inputs. Useful evidence for a threat model: filter values reaching Doctrine, error-message information leakage, and query-cost abuse. Adoption here is a mitigation you can put in a security review without a multi-sprint commitment.

Use cases where it earns its keep: public or partner-facing APIs with client-supplied filters; multi-tenant SaaS where filter params can be manipulated; admin/back-office search endpoints exposed beyond a trusted network; any API Platform surface where a 500 is a support ticket.

One correction worth carrying into the decision: despite the "Laravel/PHP" framing, this is a Symfony / API Platform component. If the roadmap item lives in a Laravel codebase, this package is not a candidate — the decision becomes "build the equivalent validation for our query layer."

When to Consider This Package

Adopt when all of these hold:

• You are on API Platform (Symfony) — this is a hard prerequisite, not a preference.
• You expose filter parameters to clients you don't fully trust, and unvalidated values currently produce 500s, driver errors, or unbounded queries.
• You need the fix this quarter, and waiting on upstream is not acceptable.
• Your team can read, fork, or vendor a small package and own it if the author walks away.
• You have an exit criterion: the PR merges, or you replace it with your own constraints.

Look elsewhere when:

• You're on Laravel or another framework. Nothing here transfers; treat it as design inspiration for a validation layer, not a dependency.
• The upstream PR has landed or is imminent. Then this package is redundant by definition and adopting it just creates a removal task.
• Your dependency policy requires active maintenance or a support path. Zero stars and zero dependents means no community, no issue triage, no security response, and effectively no signal from other teams that it survives contact with production.
• Your filters are internal-only or already validated upstream (closed enum sets, signed queries, gateway-level schema validation). Adding a dependency to re-validate trusted input is pure cost.
• You need this to be a load-bearing part of your API contract. A stopgap package is the wrong foundation for something you'd have to document and support. Roll the constraints yourself and keep ownership.

How to Pitch It (Stakeholders)

To executives: We have an API surface that accepts user-supplied filters, and right now those values aren't constrained before they hit the database. That means bad input becomes server errors, noisy alerts, and occasionally a support ticket — and it's the kind of thing a security review flags. The proper fix exists upstream but isn't merged yet. This package is a small, MIT-licensed patch that closes the gap in days rather than blocking the feature for a quarter. Cost is low and reversible; the main caveat is that it's a single-maintainer project with no adoption yet, so we treat it as temporary and calendar the removal.

To engineering: It adds validation to API Platform filter values so malformed input is rejected at the edge instead of thrown by Doctrine. Two things to be explicit about in the ticket: (1) this is a shim for api-platform/core#1723 — link the PR, set an exit criterion, and put the removal on the board the day we adopt it; (2) it's a Symfony component, so it's a non-starter for the Laravel services — those need the equivalent built in our query layer. Budget the real work as defining constraints per filter and making validation errors match our standard error envelope, not as installing the package. Given zero dependents, review the source before merging and pin the version so an abandoned release can't drift under us.