- Is slick/json-api a Laravel package or a framework-agnostic library?
- It is framework-agnostic. slick/json-api is a PHP implementation of the JSON:API specification built around PSR-7 HTTP messages rather than Laravel's Illuminate request and response classes, service container, or Eloquent. You can use it inside Laravel, but only as an HTTP-layer serialization and negotiation engine behind a PSR-7 bridge. Treat the Laravel integration as code you own and maintain.
- How do I install slick/json-api in a Laravel application?
- Install it with Composer alongside a PSR-7 implementation and bridge, such as nyholm/psr7 with symfony/psr-http-message-bridge. Register the integration as kernel middleware so incoming Laravel requests are converted into PSR-7 messages and outgoing responses are converted back. Do not expect a service provider, config file, or publishable assets, because the package does not ship a Laravel surface.
- Does slick/json-api support JSON:API 1.1, including relationship endpoints?
- The package description targets JSON:API 1.1, covering content negotiation, resource management, error handling, pagination, and custom schema definitions. Before committing, verify in the source that it supports relationship endpoints such as /articles/1/relationships/author and related links, not just top-level resources. That distinction matters if your clients rely on full relationship semantics.
- Which PHP and Laravel versions work with slick/json-api?
- Laravel 10 through 12 on PHP 8.2 or newer is compatible in principle, because the library sits at the HTTP layer and does not depend on framework internals. Confirm the actual PHP constraint in its composer.json, since the package's release provenance is uncertain. Check the tagged release on Packagist and inspect the source before adopting it.
- How do I map Eloquent models to JSON:API resources with slick/json-api?
- You write that mapping yourself. The library cannot infer JSON:API type, id, attributes, or relationships from Eloquent models, so you need a mapping layer that converts models into resource objects and handles includes, sparse fieldsets, sorting, and filtering. Keep this code in your application rather than expecting Eloquent-native behavior.
- Does slick/json-api handle sparse fieldsets, compound documents, and pagination?
- The library handles spec-level concerns such as content negotiation, error objects, and pagination links and meta. Sparse fieldsets and compound documents still require your mapping layer to decide which attributes and relationships are exposed. You must also reconcile Laravel's paginator with JSON:API's links and meta pagination contract.
- What license does slick/json-api use, and can I use it commercially?
- The license is currently reported as NOASSERTION, which is an audit and distribution blocker until resolved. Do not ship it to production or redistribute it commercially until you have confirmed the actual license terms in writing. This is a hard stop in due diligence, not a configuration issue.
- Is slick/json-api actively maintained and safe for production?
- Risk is high. It is a single-maintainer package with no dependents, no observable CI or coverage evidence, and a release date of 2026-09-25 that looks like a metadata anomaly. Resolve the license, confirm the release on Packagist, and establish maintainer contact before relying on it. Abandonment risk cannot be mitigated by configuration.
- How does slick/json-api compare to laravel-json-api and neomerx/json-api?
- laravel-json-api is Eloquent-native and actively maintained, making it the lower-friction choice for a Laravel API team. neomerx/json-api is encoder-focused and spec-oriented but is not a Laravel integration. A spatie/laravel-query-builder plus thin serializer approach gives you more control, while slick/json-api offers spec mechanics at the cost of a PSR-7 bridge and maintenance risk.
- How do I keep JSON:API error documents intact in a Laravel app using slick/json-api?
- JSON:API error documents need errors[].status, code, and source.pointer preserved, so let the library's responses escape Laravel's default exception handler. Otherwise Laravel will re-render them as its usual message, exception, and trace shape. Register the integration carefully in the kernel and test error paths explicitly.