lvntr/api-dock
API Dock is a Laravel package for organizing API endpoints in a single, discoverable registry. Define and group routes, attach middleware, and keep JSON API structure clean and consistent. It gives teams one place to manage endpoint metadata, making APIs easier to document, navigate, and maintain.
Treat this as an evaluation, not an adoption. The package has 0 stars, 0 dependents, and a release date that postdates most dependency lockfiles in the wild — there is no community surface area to lean on when something breaks. Budget an hour to read the source before it touches a shared branch.
Read the repo before installing. Open, in this order:
composer.json — Laravel/PHP version constraints, whether it pulls in heavy frontend deps (Vite, Tailwind, npm build step) or ships prebuilt assets.src/*ServiceProvider.php — what it registers: routes, views, config, commands, migrations. This tells you the blast radius faster than the README.config/api-dock.php (name per the package's publishes() call) — the enabled flag, route prefix, middleware, and auth gate all live here.routes/ inside the package — whether the dock route is registered unconditionally or behind a config check.Install pinned, not floating. With no dependents and a single maintainer, avoid ^ ranges:
composer require lvntr/api-dock --prefer-dist
# then hard-pin in composer.json to the exact tag you reviewed
If the package is not on Packagist, add it as a VCS repository and pin to a commit SHA you have read.
Publish and diff.
php artisan vendor:publish --provider="Lvntr\ApiDock\ApiDockServiceProvider"
php artisan route:list | grep -i dock
Confirm the route exists, note its URI and middleware, then open it in a browser on local only.
First use case: an internal API, one resource group. Point the dock at a single versioned API (e.g. /api/v1) with three or four endpoints backed by FormRequests and API Resources. Compare what the dock renders against php artisan route:list --json. The delta — endpoints missing, params wrong, response shapes guessed — is your real feature list and your real risk list. Do this before you show it to anyone.
Decide the exit criteria now. Write down what would make you keep it (does it infer request bodies from FormRequest rules correctly? does the try-it console handle Sanctum?) and what would make you drop it (breaks on route:cache, requires an npm build in CI, unmaintained for a quarter). Scramble and Scribe are the incumbent alternatives; the comparison is cheap and you should run it in parallel on the same API.
Gate the dock behind config + authorization, never just a route prefix. The single most common failure mode for packages like this is shipping an endpoint that enumerates your internal API surface to whoever finds the URL.
// config/api-dock.php (adapt to actual keys)
'enabled' => env('API_DOCK_ENABLED', false),
'middleware' => ['web', 'auth'],
'gate' => fn ($user) => $user?->can('viewApiDocs'),
Then in a service provider, make the gate explicit rather than relying on the package default:
Gate::define('viewApiDocs', fn (User $user) => $user->isStaff());
Keep API_DOCK_ENABLED=false in .env.example and in every non-local environment file. Do not derive it from app()->isLocal() alone if your staging box is internet-reachable.
Keep route definitions single-source. Inference-based dockers read your route table. If you register the same controller under two prefixes, or duplicate routes in routes/api.php and a service provider, the dock will render duplicates or drop one silently. Consolidate first, document second.
Lean on type information the framework already has. The quality of generated docs tracks how strictly you type: FormRequest rules for request bodies, JsonResource / ResourceCollection for response shapes, enum casts for allowed values, and explicit return types on controller methods. Where inference fails (closures, Route::match, dynamic prefixes, polymorphic relations), add the package's per-route override — attributes or docblocks, whichever it exposes — rather than reshaping production code to satisfy a doc generator.
Split documents by audience, not by controller. One dock for the internal team (everything), one for partners (a curated subset). If the package supports multiple "documents"/"groups," configure them from explicit route-name allowlists so a newly added internal endpoint does not leak into the partner view by default.
Generate a static spec in CI and diff it. If the package can emit OpenAPI JSON via an artisan command, wire it into a build step:
php artisan api-dock:export --format=openapi > build/openapi.json
git diff --exit-code build/openapi.json
This gives you three things cheaply: a reviewable artifact, drift detection when someone changes a signature, and a spec you can feed to Schemathesis or Dredd for contract tests. It also means the dock is a build-time tool, not a runtime dependency — which is exactly where you want an unvetted package to sit.
Test the dock like a feature. One test asserting the route is 404 when disabled and 200 for an authorized user, plus one asserting a known endpoint appears in the output. That test is your regression alarm for a package with no downstream users to notice breakage.
For the try-it console, scope base URLs and tokens per environment in config, and use a dedicated read-only API token. Do not let the console inherit the developer's session cookie and default to production.
DB::listen, a debug dump, or an unconditional route registration in a service provider is not paranoia here, it is due diligence.composer.lock records a real commit, and that the repository is not a placeholder or a rename of something else. Check the commit history for depth — a single squashed "initial commit" tells you the code has never been through review.route:cache interaction. Packages that register routes dynamically from config often break or silently vanish under php artisan route:cache. Test the cached path explicitly:
php artisan route:cache && php artisan route:list | grep -i dock
php artisan route:clear
config:cache interaction. env() calls inside the package's source (rather than inside a config file) return null once config is cached. If the dock is "enabled" in dev and dead in CI, this is almost always why.config:clear after publishing. A stale published config from an earlier version is the usual cause of "the new option does nothing."route:list --json to confirm the route table the package actually sees; (2) middleware order — a TrimStrings/ConvertEmptyStringsToNull pair or a custom api group can change what the inferrer reads; (3) storage/logs/laravel.log for reflection or type errors swallowed during render; (4) publish the views and dd() the collected route/schema array. Do not debug through the UI.Route::match produce garbage or nothing. Replace them with invokable controllers or explicit overrides; do not file it as a package bug you can wait out.How can I help you explore Laravel packages today?