- What does essa/api-tool-kit actually do?
- It is a Laravel package that bundles cross-cutting API behaviour: query filtering, sorting, pagination, eager-load includes, standardised JSON response envelopes, error handling and validation helpers. It ships as a service provider plus publishable config, and you opt in per route group via middleware or traits. The stated goal is cutting boilerplate so you can focus on writing endpoints. Treat it as a convention bundle rather than a single-purpose helper, because it also encodes opinions about your API's response contract.
- How do I install essa/api-tool-kit in a Laravel app?
- Run composer require essa/api-tool-kit, let Laravel package auto-discovery register the service provider, then publish the config with vendor:publish and adjust it to your needs. You then wire it into the route groups where you want the behaviour, using the provided middleware or traits. A competent Laravel developer can usually get a spike running in under a day. The real cost is not installation but standardising every existing controller, resource and exception path to conform.
- Which Laravel and PHP versions does essa/api-tool-kit support?
- The package targets Laravel applications and integrates through Laravel-native surfaces such as middleware, the exception handler's render path and Eloquent query builders. The published material does not state a supported-version matrix or a policy for new Laravel majors, so check composer.json and the CI matrix in the repository before committing. This matters because Laravel majors regularly ship breaking changes to the exception handler, JsonResource and pagination internals. Ask the maintainer directly what happens on the next major release.
- Does essa/api-tool-kit force a response envelope on every endpoint?
- That is one of the key open questions flagged in technical evaluation: is the response envelope mandatory, or is each concern independently toggleable? Partial-adoption capability is the single biggest factor in exit cost, so verify it early in your spike. If concerns are not independently toggleable, adopting the package means adopting its response shape, error format and filter syntax across every endpoint. Those decisions are cheap to make before clients consume your API and expensive to reverse afterwards.
- How does essa/api-tool-kit compare to spatie/laravel-query-builder?
- Both cover filtering and sorting, but spatie/laravel-query-builder is a focused leaf dependency while essa/api-tool-kit is a broader bundle that also handles response envelopes, error handling and validation helpers. If all you need is query filtering, a narrower package is easier to reason about and cheaper to swap out. If you want one consistent convention across all endpoints, a bundle saves you assembling several packages yourself. Either way, run a conflict check against your likely neighbours such as laravel/sanctum, dedoc/scramble and league/fractal.
- Is essa/api-tool-kit safe to use in production?
- The adoption signal is weak: the package has attracted stars but essentially zero dependents, so there is no battle-tested consumer you can point to. Single-maintainer MIT packages are common and fine for leaf utilities, but riskier for something that owns your response contract. Before a go decision, check test coverage, CI status across the supported matrix, and open issue and PR response times over the last two quarters. Also verify the registry metadata, since a release date in the future and a one-line description suggest stale or unreliable data.
- Can I use essa/api-tool-kit alongside Laravel API Resources and Sanctum?
- In principle yes, since it hooks the same Laravel-native surfaces such as middleware, exception rendering and Eloquent builders. The risk is overlap: Laravel already ships API Resources, Sanctum and improved exception rendering natively, so you end up with duplicate abstractions if you are not deliberate. Decide whether your contract lives in the package's envelope or in native Resources, not both, and confirm there is no conflict with any existing filtering or documentation package in your stack.
- How does essa/api-tool-kit handle validation errors and exceptions?
- The package provides error handling and validation helpers plus standardised JSON responses, typically by hooking into the exception handler's render path so API errors come back in a consistent shape instead of Laravel's mixed defaults. Because that surface changes across Laravel majors, confirm the emitted format matches what your clients already expect. Also verify behaviour for 404s, 422 validation failures and unexpected 500s, including whether debug details leak in non-production environments.
- How do I test endpoints that use essa/api-tool-kit?
- Test at the HTTP level using Laravel's built-in test helpers, asserting the JSON structure produced by the response envelope and the behaviour of filter, sort and pagination query parameters. Because the filter syntax is the package's own convention, add coverage for both accepted and rejected parameter combinations, including invalid sorts and unknown filter keys. If the package is toggled per route group, test the enabled and disabled paths separately. Keep those assertions in a shared test helper so a future swap to another package is a one-file change.
- How hard is it to remove essa/api-tool-kit if it gets abandoned?
- That depends almost entirely on partial adoption: if each concern can be toggled independently, removal can be incremental, but if the response envelope is mandatory you are unwinding conventions across every endpoint. Before adopting, ask about a second committer, a funding model and any stated deprecation path, and confirm who tracks new Laravel majors. If it is abandoned mid-cycle, your realistic options are forking it or standardising on Laravel's native Resources and exception rendering and ripping the package out.