Laravel API Toolkit: conventions, a generator and an AI skill

A package of conventions rather than a framework

Laravel API Toolkit describes itself as the all-in-one solution for building efficient APIs with Laravel, and the introduction is more precise than that: build production-grade Laravel APIs with standardized responses, dynamic pagination, advanced filtering, and built-in AI architectural rules that teach your coding assistant to follow your standards from the first draft.

So the package is two things. The first is a set of runtime features: the response format, the pagination, the filtering, action classes, a media helper and enum support. The second is a set of rules and workflows that are installed into your repository so an AI assistant writes code in the shape you want.

The installation is one Composer command:

composer require essa/api-tool-kit

The package is on Packagist as essa/api-tool-kit, with badges for the latest version, the test status and the total downloads. It is MIT licensed, and the documentation site is laravelapitoolkit.com.

The release history tells you which way the project is moving, and the version titles are unusually informative. Version 3.0.0 in February 2026 is titled Modernization, PSR-12, Native PHP 8.1 Enums, and Max Pagination Limit. Version 3.1.0 a couple of days later is AI-Ready Architectural Skill and Installation Command. And v3.2.0 in March 2026 is AI-First Architecture Overhaul and PHP 8.4 Support.

So a 3.0 that cleaned up the code style and moved to native enums, a 3.1 that added the AI Skill, and a 3.2 that reorganised around it. That is a package that changed direction in the space of a month, which is worth knowing before you adopt it.

The last push to the repository was on 2026-04-24, and the primary language is PHP with the default branch master.

The AI Skill: 21 rules and 8 workflows

The feature that distinguishes this package is the AI Skill, and it is the one worth reading the README section for carefully.

One command installs 21 rule files and 8 guided workflows that ensure every AI-generated file fits your codebase from the first draft, with no manual corrections needed. It supports Claude Code, Cursor, GitHub Copilot and Antigravity.

The full experience gives you slash commands, auto-loaded rules and per tool native configuration:

php artisan api-skill:install [tool]

The supported tools are claude, cursor, copilot and antigravity. The installer copies rules and workflows to the correct location for your tool, so commands like /investigate, /code-review and /new-endpoint become real slash commands in Claude Code.

The quick setup goes through Laravel Boost and is agent-agnostic, working with all AI tools:

php artisan boost:add-skill ahmedesa/laravel-api-tool-kit

That installs into .ai/skills/laravel-api-tool-kit/, a universal location that Claude Code, Cursor, Copilot, Antigravity and Gemini all read from on demand. No slash commands, but zero configuration.

There is a tip for non-interactive environments, Docker and CI, where the selection prompt is a problem:

php artisan boost:add-skill ahmedesa/laravel-api-tool-kit --skill=laravel-api-tool-kit

The distinction between the two routes is the interesting design decision. The per tool install gives you real commands in one assistant and nothing in the others, while the universal location gives every tool the same rules at the cost of not having commands. A team that uses one assistant wants the first, and a team that uses several wants the second.

What the rules actually contain is the next section, and the claim the README makes about them is strong: the AI Skill is the recommended way to generate code for projects using this package, and it replaces the need for scaffolding generators by teaching your assistant the full architecture.

What the rules and workflows cover

The contents table in the README is the clearest description of what the package wants your codebase to look like, and it is worth reading as a style guide rather than as a feature list.

The rules cover Controllers, Models, Actions, DTOs, Services, Repositories, Filters, Enums, Events, Requests, Resources, Responses, Exceptions, Authorization, Testing, Database, Pagination, Anti-patterns, Code Quality, DDD and Dependency Injection. That is a complete layering for a Laravel application, and the presence of both Repositories and Services, alongside DTOs and Actions, means the rules assume a layered architecture rather than the fat controller style.

The workflows are the tasks: new endpoint, add filtering, code review, investigate, curl-test, organize knowledge, update knowledge and create workflow. The first four are the obvious ones. Organize knowledge and update knowledge suggest that the rules are meant to be maintained as living documentation inside the repository rather than as a fixed file, and create workflow suggests you can add your own.

The DDD support line says it works with both standard Laravel and Domain-Driven Design layouts, which is a practical detail: the same rules have to apply whether your directory structure is app/Http/Controllers or a domain folder with aggregates and value objects.

The project defaults line is the piece that will save the most time. You configure the primary key type, the auth guard and the test base class once, and the AI applies them everywhere. Those are exactly the three things that an assistant gets wrong when it writes code from scratch, and getting them right once in the rules is cheaper than correcting them in every file.

So the AI Skill is a structured conventions file with twenty-one topics and eight procedures, plus a mechanism for distributing it. The claim is that this replaces a generator, and the mechanism by which it does so is teaching rather than templating.

The runtime features: responses, pagination, filtering and actions

The parts that run in your application are conventional Laravel code with a Laravel shape.

The API Response feature provides a standardized format for your API responses, with the shape shown in the README:

{
  "message": "your resource successfully",
  "data": [
    ...
  ]
}

Dynamic pagination adapts to your needs, giving you control over the number of results per page without managing it by hand:

$users = User::dynamicPaginate();

Filtering lets you filter, sort, search and include relationships:

Car::useFilters()->get();

Actions handle business logic and follow the command pattern, and the README's controller example shows how they are meant to be wired in, with the action injected through the constructor and executed with the validated request data:

class CarController extends Controller
{
    public function __construct(
        private readonly CreateCarAction $createCar,
    ) {}

    public function store(CreateCarRequest $request): JsonResponse
    {
        $car = $this->createCar->execute($request->validated());
        return $this->responseCreated(trans('car.created'), new CarResource($car));
    }
}

That example is small but it carries the conventions: a request object for validation, an action for the logic, a resource for the output and a response helper for the envelope.

The Media Helper handles file uploads with a single call, MediaHelper::uploadFile($file, $path), and the Enum class provides a way to work with enumerations, eliminating hardcoded values, with the example showing a backed enum with an ADMIN and a STUDENT case.

The API Generator is still there for people who prefer scaffolding:

php artisan api:generate ModelName --all

It automates file setup, creating key files from migrations to controllers. The README's note is explicit that for AI-assisted development the AI Skill is the recommended approach, and that the generator remains available for developers who prefer traditional scaffolding.

The repository, and how the tools are packaged

The repository layout shows how the package serves two different consumers, the PHP application and the coding assistant.

The PHP side is the src/ directory with a config/ directory beside it, the tests/ directory, a phpunit.xml for the test configuration and a pint.json for code formatting, since Pint is the formatter the Laravel ecosystem uses. There is a composer.json and composer.lock, so the dependency set is pinned.

The assistant side is the interesting part. There is a skills/ directory holding the rule files and the workflows, and then .claude-plugin/ and .cursor-plugin/ directories, which are the per tool plugin manifests for Claude Code and Cursor. That is what makes the per tool installation path a first class feature rather than a set of file copies.

There is also a docs/ directory for the documentation, a CONTRIBUTING.md for the contribution guidelines, and a Readme.md with the project banner images, api-generator.png and laravel-api-tool-kit.png, in the repository root.

The licence terms are stated in the contributing section rather than only in the licence file: by contributing to the Laravel API Toolkit, you agree that your contributions will be licensed under the project's MIT License, in the LICENSE.md file.

The documentation lives at laravelapitoolkit.com and the README links the full AI Skill documentation there. There is also a video tour on the Laravel Package Tutorial channel, linked with a thumbnail, for people who would rather watch the features demonstrated than read about them.

Where the Laravel API Toolkit is the wrong choice

There are cases where this package is the wrong answer, and they are mostly about agreeing with it.

The first is the response envelope. Every endpoint inherits a message and a data shape, and if your API contract is different, or if you already have clients depending on a different shape, then the package's central convention is a cost rather than a benefit. You can work around it, but then you are using the package for everything except the thing it is named after.

The second is that the package writes into your repository. The AI Skill installs rules and workflows into.ai/skills. That is a deliberate design and it is also a coupling: your repository now contains files whose meaning depends on a tool and a package version, and a team that later changes its mind has to clean them up.

The third is that the rules are opinionated about architecture. Repositories, Services, Actions and DTOs are the layering the rules describe, and if your team has settled on a different one, the assistant will keep producing code in the package's shape until somebody corrects it, which is the thing the rules were supposed to prevent.

The alternative approach is to build the conventions yourself, as an internal package with your own response helper and your own architecture notes, and to enforce them with a linter and an architecture test rather than with rules for an assistant. The difference in approach is that the toolkit gives you a maintained set of conventions and a distribution mechanism for them, while the hand-rolled route gives you exactly the conventions you have and nothing else to learn, at the cost of maintaining it.

For a team starting a new API with no settled conventions, the toolkit's defaults are the reason it exists. For a team with settled conventions that differ, it is one more thing to fight.

Editorial conclusion

Laravel API Toolkit suits a team that has already agreed how its API should look and wants that agreement enforced rather than repeated, and it suits a team that uses an AI coding assistant and would rather the assistant knew the rules than being corrected after every file. It does not suit a project whose API contract is different from the package's defaults, because the response envelope, the pagination behaviour and the filtering semantics all come from the package rather than from you. Check three things before you adopt it: that you want the standardized envelope, since every endpoint inherits it, that you are happy for the package to write files into your repository, since the AI Skill installs rule and workflow files into your repository, and which Laravel version and PHP version you are on, since the release history shows the 3.x line modernising towards native PHP 8.1 enums and PHP 8.4 support. The last push to the repository was on 2026-04-24 and the newest release is v3.2.0.

Frequently asked questions

Official sources

1. ahmedesa/laravel-api-tool-kit on GitHub
2. License: MIT
3. Project website
4. README
5. Releases