Api Access Api Laravel Package

Getting Started

This package is a presentation adapter — the HTTP/API surface layer for a separate api-access domain module. It very likely contains routes, controllers, requests, and API resources but not the domain logic or models. Treat anything you read here as a working hypothesis and confirm against the repo before you build on it.

Minimal steps:

composer require liberusoftware/api-access-api

1. Read composer.json first. Check the require block — you almost certainly need the sibling domain module (something like liberusoftware/api-access) and a Laravel version constraint. If it requires a specific framework major, match it before installing.
2. Check provider registration. Laravel 11+ uses bootstrap/providers.php; older versions use config/app.php. If the package relies on package discovery, verify with:

   php artisan about
   php artisan route:list --path=api
   

3. Publish what's publishable. Look for a service provider with publishes() calls for config, migrations, or route files:

   php artisan vendor:publish --provider="Liberu\ApiAccessApi\ApiAccessApiServiceProvider"
   

4. Inspect routes/ in the package source. That directory tells you the real endpoint surface faster than any README — route prefixes, middleware groups, and versioning all live there.

First use case: wire the adapter into a host app that already runs the domain module, hit one read endpoint with a valid token, and confirm the response shape. Don't attempt provisioning/token-issuance flows until a single authenticated GET works end to end. That single request exercises provider registration, middleware, guard config, and resource serialization all at once.

If you're not already inside a Liberu modular host application, assume significant integration work. These packages are designed to compose with their siblings, not to stand alone.

Implementation Patterns

Keep the adapter thin. The value of a presentation adapter is that it maps HTTP to domain calls. Resist adding query logic to controllers:

public function store(StoreAccessRequest $request, IssueTokenAction $action): JsonResponse
{
    $token = $action->handle(
        Dto::fromRequest($request)   // adapter's job
    );

    return TokenResource::make($token)   // adapter's job
        ->response()
        ->setStatusCode(201);
}

Resolve actions through the container rather than new-ing them — that's how you swap implementations in tests.

Bind to contracts, not concretes. If the adapter depends on an interface from the domain module, you can substitute a fake:

$this->app->bind(TokenIssuer::class, fn () => new FakeTokenIssuer());

This is the single most useful extension point. It lets you test the HTTP layer without touching a real database or external identity provider.

Middleware and ability checks. Authorization almost certainly belongs to the domain module, but the adapter decides where it runs. Check the route group's middleware stack in routes/:

Route::middleware(['auth:sanctum', 'ability:api-access:read'])
    ->prefix('api/v1')
    ->group(function () { /* ... */ });

If you need custom guards or scopes, prefer overriding config over editing vendor files.

Resource/response shaping. If the package ships API Resources, extend them rather than replacing them — class MyTokenResource extends TokenResource and override toArray(). You keep upstream fixes and control the wire format.

Testing pattern that works well here:

it('rejects unauthenticated access', function () {
    $this->getJson('/api/v1/access')->assertUnauthorized();
});

it('lists access records for the authenticated owner', function () {
    $user = User::factory()->create();
    Sanctum::actingAs($user, ['api-access:read']);

    $this->getJson('/api/v1/access')
        ->assertOk()
        ->assertJsonStructure(['data' => [['id', 'name']]]);
});

Integration tip: if the domain module emits events (TokenIssued, AccessRevoked), listen for them in your app rather than polling. That's the cleanest seam between the adapter and your application's concerns.

Gotchas and Tips

License is NOASSERTION. This is the biggest blocker. GitHub could not identify a standard license, which for a commercial or open-source product means you have no granted rights until counsel reviews the LICENSE file in the repo. Resolve this before writing production code against it.

Adoption risk is real. Zero stars, zero dependents, and a release date that hasn't happened yet relative to most usage. Practically:

• Pin an exact version ("liberusoftware/api-access-api": "1.2.3"), never a caret range.
• Commit composer.lock.
• Consider vendoring the source into your repo so an upstream force-push or deletion can't break your build. At this adoption level, upstream availability is not a guarantee.

Namespace and autoload collisions. Modular Liberu packages share a vendor namespace and often a Liberu\... PSR-4 root. If two modules register overlapping prefixes, you get confusing "class not found" errors that look like caching bugs. Check composer.json autoload.psr-4 and run:

composer dump-autoload -o

Cache staleness is the #1 false alarm. After publishing config or adding routes:

php artisan optimize:clear
php artisan route:list --path=api -v

If a route 404s that should exist, it's usually route:cache holding a stale snapshot — not a broken package.

Migration ordering. If the adapter ships migrations (it might, for a tokens or audit table), they can collide with the domain module's. Namespace your own migrations with a later timestamp, and never edit published migrations after they've run in a shared environment.

Don't add domain logic here. The temptation when an endpoint is missing a field is to reach into the database from the adapter. That breaks the module boundary and will be overwritten conceptually on the next upstream release. Extend the domain action or add a decorator instead.

Debugging checklist, in order:

1. php artisan about — is the provider loaded?
2. php artisan route:list --path=<your-prefix> — did routes register?
3. php artisan tinker → app(TokenIssuer::class) — does the container resolve the dependency?
4. Response shape wrong? Check for a published config/api-access-api.php overriding defaults.
5. APP_DEBUG=true plus Log::debug() inside the middleware group to confirm the request reaches the adapter at all.

Extension points worth checking in source: published config keys, container bindings in the service provider's register(), Macroable traits on resources, and any tap() or extend() hooks. Those four spots cover most of what a presentation adapter legitimately exposes for customization.