$request->filtering().
1. Declare filters on the route
::equals, ::in, ::like, ::contains, ::greaterThan, ::lessThan) binds a filter operator to a property. Not all filters support all operators — match them by type:
| Filter class | Operators |
|---|---|
StringFilter | equals, in, like, contains |
EnumFilter | equals, in |
IntegerFilter, FloatFilter, DateFilter, DateTimeFilter | equals, in, greaterThan, lessThan |
ByteFilter, BinaryFilter | equals, in |
2. Clients send filters as flat query parameters
RequestValidationMiddleware rejects anything you didn’t declare. Wrong type (age=not-an-integer) → 422. Unknown filter (?foo=bar where foo isn’t declared) is silently ignored.
3. Read values in the controller
$request->filtering() returns a FilterBag. Each filter exposes its operator via the isType*() methods and its value via getValue(), already cast to the correct PHP type.
$filters->has('name') returns false and $filters->name returns null — the bag is not populated with defaults for filters (unlike sorting).
4. Iterate when you want to apply them generically
Inside a resource
Resources exposeavailableFilters():
AbstractListResourceController wires them into the route for you — the controller reads from $request->filtering() exactly the same way. See the resource CRUD how-to.
OpenAPI side effects
Each declared filter becomes a dedicated query parameter in the generated spec, typed from the underlyingAbstractProperty. Descriptions include the operator ("Name contains", "Minimum age (years)"). Swagger UI will render a separate input per filter — you can’t generate ?filter[name]=... style syntax with this system.