Getting Started
Laravel API Generator scaffolds a complete, production-style REST API from a single artisan command: model, migration, controller, service, DTO, form request, resource, policy, factory, seeder and written tests.
Requirements
- PHP >= 8.2 (>= 8.3 for Laravel 13)
- Laravel 12.x or 13.x (Laravel 10 and 11 projects stay on
^3.15, see Upgrading to 4.0)
Installation
composer require --dev nameless/laravel-api-generatorThe service provider is auto-discovered. No configuration required.
Zero lock-in
The generator is a dev dependency: it never runs in production (composer install --no-dev leaves it out), and the generated code is plain Laravel with no dependency on this package (no base classes, no runtime helpers). You can even remove the generator afterwards and everything keeps working.
Your first API
php artisan make:fullapi Post --fields="title:string,content:text,published:boolean"Then:
php artisan migrate
php artisan testThe suite passes right after generation, with real assertions against real endpoints, where most generators leave you skeletons to fill in.
What gets generated
One command creates 13 files per entity and registers the API route:
| Layer | File | Location |
|---|---|---|
| Model | Post.php | app/Models/ |
| Controller | PostController.php | app/Http/Controllers/ |
| Service | PostService.php | app/Services/ |
| DTO | PostDTO.php | app/DTO/ |
| Requests | StorePostRequest.php, UpdatePostRequest.php | app/Http/Requests/ |
| Resource | PostResource.php | app/Http/Resources/ |
| Policy | PostPolicy.php | app/Policies/ |
| Factory | PostFactory.php | database/factories/ |
| Seeder | PostSeeder.php | database/seeders/ |
| Migration | *_create_posts_table.php | database/migrations/ |
| Feature Test | PostControllerTest.php | tests/Feature/ |
| Unit Test | PostServiceTest.php | tests/Unit/ |
| Route | apiResource entry | routes/api.php |
The generated architecture
Every request flows through a clean, layered structure:
The controller stays thin. It asks the policy, then delegates to the service:
public function update(UpdatePostRequest $request, Post $post)
{
Gate::authorize('update', $post);
$dto = PostDTO::fromRequest($request);
return new PostResource($this->service->update($post, $dto));
}Business logic lives in PostService, data crosses layers as a typed, readonly PostDTO, and PostPolicy decides who may do what. The generated policy lets everyone through, guests included, so the API works right away and restricting it means editing one method. Updates accept a partial payload: a PATCH changes the fields it sends and leaves the others alone. When your API grows, the right places to put things already exist.
Models your IDE understands
Every generated model ships a complete PHPDoc block: fields, FK columns, relations, timestamps:
/**
* @property int $id
* @property string $title
* @property \App\Enums\Status $status
* @property \Illuminate\Support\Carbon|null $published_at
* @property-read \Illuminate\Database\Eloquent\Collection<int, Comment> $comments
*/
class Post extends ModelAutocomplete works instantly in VS Code and PhpStorm, without ide-helper for the generated code.