Weave Code
Core Api Laravel Package
fleetbase/core-api
Core API package for Fleetbase, the open-source logistics and fleet management platform. It provides the REST API foundation—routes, controllers, resources, authentication, and extension points—for building dispatch, tracking, and fleet operations services on Laravel.
Fleetbase API Core
Frequently asked questions about Core Api
- How do I install fleetbase/core-api in a Laravel application?
- Install it with Composer using composer require fleetbase/core-api. It is a Laravel-native package, so it integrates through your application's service provider and configuration rather than a separate runtime. Check the package README for any publishable config or route registration steps for your Fleetbase setup. Version 1.6.71 adds no migrations, so installation and upgrades are mainly Composer and cache steps.
- Which Laravel versions are supported by fleetbase/core-api?
- fleetbase/core-api is built as a Laravel-native Composer package, but the supported Laravel version range is defined in its composer.json rather than in the API docs. Check that constraint against your application before upgrading, especially if you run Laravel Octane. The 1.6.71 release focuses on API behavior and cache scoping, not framework-version changes.
- What does the socket settings API in fleetbase/core-api v1.6.71 do?
- Version 1.6.71 adds GET and POST int/v1/settings/socket endpoints for administrators to manage realtime channel authentication. You can set the switch, mode (off, log, or enforce), token TTL, allowed origins, and publisher origin, and a signed GET int/v1/socket/config endpoint lets the socket server poll the current runtime configuration. Every value falls back to the environment until an administrator saves a setting, and SOCKETCLUSTER_AUTH_KEY remains in the environment and is never stored or returned. Saves are written to the activity log, but you should explicitly confirm the authorization boundary and the impact of an enforce-mode misconfiguration.
- Why did my Fleetbase API cache return live data in test mode?
- That was a known issue fixed in 1.6.71: cache keys did not include the database connection, so a console request in test mode could be served a cached live response for the same query. Console sessions carry no API credential to distinguish them, which is why the connection scope matters. After upgrading, the new keys use the connection, such as {api_query}:mysql or {api_query}:sandbox, and deploying with php artisan cache:clear resolves the transition. Old entries would otherwise expire in about 5 minutes for lists and 1 hour for models.
- What is the filter cache bug fixed in fleetbase/core-api v1.6.71?
- The fix addresses Find::httpFilterForModel, which cached filter resolution per model class for the life of the process and could ignore a controller's own $filter and request audience. Under Octane, the first controller to list a model could decide the filter for every other controller, which is a cross-tenant correctness and potential data-exposure risk. Upgrading to 1.6.71 is the remediation, but any earlier version running on Octane should be reviewed for incorrect scoping in production. Check logs and prior exposure as part of the upgrade review.
- Is the driverAssigned event deprecated in fleetbase/core-api?
- Yes. driverAssigned.* events are still published in 1.6.71 but are now deprecated. Lifecycle events for records with an assigned driver are additionally published on driver.{public_id} and driver.{uuid}. Clients that follow the {type}.{id} convention should be validated against the new channels. Clients relying only on driverAssigned.* should be scheduled for migration.
- How does fleetbase/core-api handle authentication and authorization?
- The package provides authentication and authorization hooks as part of the Fleetbase API foundation. In 1.6.71, the socket-settings API adds a privileged write surface, so you should confirm who can call int/v1/settings/socket and how that permission is enforced. The SOCKETCLUSTER_AUTH_KEY stays in the environment and is never stored or returned, and turning the socket switch on without a key is refused. Saves are activity-logged, which helps with audit review.
- Do I need to run migrations when upgrading to fleetbase/core-api 1.6.71?
- No. The 1.6.71 release notes state that upgrade steps are otherwise none and the package adds no migrations. The main operational step is cache clearing, and deploy.sh already runs php artisan cache:clear, which resolves the connection-scoped cache-key transition. Without that clear, old entries expire naturally in about 5 minutes for lists and 1 hour for models.
- How do I extend fleetbase/core-api with custom API resources and routes?
- fleetbase/core-api is structured around modular controllers, models, services, and extensible API routing for custom resources. You extend it by adding your own controllers and routes alongside the core Fleetbase resources, then reusing the package's models and services where they fit. Keep your custom filter logic explicit rather than relying on the patched Find::httpFilterForModel behavior, especially under Octane. Also confirm that your package pins resolve against ^1.6.71 so every service uses the same API foundation.
- What are the production risks of running fleetbase/core-api on Laravel Octane?
- The biggest Octane-specific risk in earlier versions was the filter cache bug, which could apply one controller's filter to another tenant's request and produce incorrect scoping. Upgrading to 1.6.71 is remediation, but you should review logs from prior deployments for signs of cross-tenant data exposure. The connection-scoped cache keys also fix test/live cache bleed, and the socket-settings feature adds a privileged configuration surface that deserves explicit authorization review. Confirm that no package pins fleetbase/core-api below 1.6.71.
Weaver
How can I help you explore Laravel packages today?