# Apiato: a Laravel starter kit organised around the Porto SAP pattern

> A PHP framework distribution rather than a library, with generators for code and documentation, API versioning, hashed identifiers and a container split that you own outright. The trade is a large opinionated skeleton you will have to learn before you can delete the parts you do not want.

**apiato/apiato** — PHP Framework for building scalable API's on top of Laravel.

- Repository: https://github.com/apiato/apiato
- Website: http://apiato.io
- Stars: 3,106 · Forks: 471
- Language: PHP
- License: MIT
- Published: 2026-10-06 · Updated: 2026-10-06 · Language: en
- Canonical page: https://hysenlabs.com/projects/apiato-apiato

## A starter kit you install as a project, not a package you install

Apiato calls itself a PHP framework built on top of Laravel, but the install command tells you what it actually is:

```bash
composer create-project apiato/apiato
```

That is `create-project`, the Composer command that clones a template into a fresh directory. You are not adding Apiato to an existing application. You are starting from a repository that already contains a complete, opinionated Laravel application, and Apiato's job is to keep that skeleton current.

That distinction explains the release notes better than the feature list does. When v13.0.0 says a lot of files were moved around, renamed or removed, and points at changelogs for both Apiato and its Core repository, it is describing a template restructure rather than a library major version bump. The v13 release moved the minimum PHP version to `^8.2` and the minimum Laravel version to `^11.23`, renamed the generate command from `apiato:generate` to `apiato:make`, added a Response facade, and moved an abstract class namespace from `Apiato\Core\Abstracts` to `Apiato\Core`. Those are the kinds of changes that matter because your code has to follow them, not because a dependency resolved differently.

The repository topics describe it accurately as a starter kit, starter app and starter project. The word to hold onto is starter.

## Porto SAP decides where every class belongs before you write it

The architectural commitment is the Porto SAP pattern, a port and adapter layering that Apiato inherited from a related project. The practical effect is that the `app/` directory is not a conventional Laravel layout where you drop controllers wherever you like. It is layered, with each layer having a defined dependency direction, and the generators place new classes in the layer their role belongs to.

This is the main thing to evaluate before you start. Porto SAP is opinionated and it is not the Laravel default, so a developer arriving from an ordinary Laravel app will spend real time internalising where things go. In exchange you get the same answer to structural questions in every project, which is the argument Porto and Apiato both make.

The repository tree shows the supporting infrastructure around that layering. `app/` holds the application code, `database/` the migrations and seeders, `config/` the configuration, `routes/` the route definitions, and `resources/` the frontend sources. Alongside them sit the quality tools a team would otherwise assemble by hand: `phpstan.neon.dist`, `psalm.xml`, `ruleset.xml`, `.php-cs-fixer.dist.php` and `phpunit.xml`. Running static analysis through both PHPStan and Psalm, with a shared rule set and a code style fixer, is a reasonable default for a template that claims to be testable.

## Generators for code and for documentation, kept as separate concerns

Two generator features sit at the top of the README's list. The first creates code, the entity and its layers. The second builds API documentation, and the fact that they are separate items rather than one combined command is a design signal: documentation generation runs over the finished surface, not alongside the scaffolding.

The repository supports this with tooling visible in `package.json`. The JavaScript side is small and Vite-based:

```json
"build": "vite build",
"dev": "vite"
```

The dev dependencies tell you more. `laravel-vite-plugin` wires Vite into Laravel, Tailwind sits at `^3.4.13` with PostCSS and Autoprefixer, and `apidoc` at `^1.0.0` is present as a documentation generator alongside `axios` and `concurrently`. `vite` itself is at `^6.0.11`. That is a conventional modern frontend stack for a Laravel application with an admin interface, and the tailwind config plus vite config at the root confirm the UI side is part of the template rather than something you bolt on afterwards.

The feature list also names API versioning for backward compatibility, pagination, caching, ETag support, localisation, social authentication and query parameters. For a template, the useful question is not whether these are present but whether they are configurable, and that is where the documentation at apiato.io does the real work.

## Environment defaults reveal what the framework expects from you

The `.env.example` at the root is more informative than most of the README, because it states every default the framework will assume. The interesting entries are the ones that would surprise you:

```bash
HASH_ID=true
HASH_ID_KEY=apiato
HASH_ID_LENGTH=16
```

Hashed identifiers are on by default. Instead of exposing sequential database IDs in API responses, Apiato encodes them, with a length and a salt supplied by `HASH_ID_KEY`. It is a reasonable default for an API-first application, and it is also a decision you will be living with, because anything that accepts an ID from a client has to resolve it.

Other defaults worth knowing: the global API rate limiter is enabled at 30 attempts per minute with a one minute expiry, pagination defaults to 10 items, the Eloquent query cache is off with a 60 second window if you switch it on, API tokens expire after 1440 minutes and refresh tokens after 43200, and bcrypt runs at 12 rounds. Sessions, cache and the queue all default to the database driver, mail falls back to the log channel, and the file system disk is local.

For local work the database connection defaults to SQLite, with the MySQL settings present but commented out. That choice makes `composer create-project` runnable without a database server, and it is also a hint that the SQLite default is a convenience rather than the intended production target.

## Removing Passport in v13 says something about the authentication story

Among the notable changes in v13.0.0 is the removal of the `laravel/passport` dependency, alongside the addition of a Response facade, new helper functions and new macros. Removing a well-known OAuth package is the kind of change that deserves an explanation, and the release notes do not give one beyond the upgrade guide link.

The feature list still advertises OAuth 2.0 authentication, so the capability did not disappear; the implementation moved. If you are evaluating the authentication model specifically, that is the detail to read up on in the documentation rather than infer from a dependency removal.

Version support then moved forward twice. v13.1.0 in May 2025 added Laravel 12 support and links to the same upgrade guide, and v13.2.0 in November 2025 shipped a modern responsive UI, credited as a first contribution from a new contributor. The release notes for v13.1.0 also include a note about the cost of open source work, stating the release took around three work days and pointing at the project's consultancy and support offering.

That combination of a template plus paid support is the real commercial shape of Apiato. It is maintained by a small named group, offers dedicated consultancy, and is sponsored through Open Collective with Laradock among the gold sponsors. The last push was on 2026-05-29 and the repository is not archived, so the cadence is real but slow enough that you should pin versions.

## What you inherit if you start from the template

The honest way to assess Apiato is to compare it with the alternative of a bare Laravel install plus a handful of packages. Laravel alone gives you routing, the container, Eloquent, queues, caching and a test harness. Apiato adds the Porto SAP layering, the generators, documentation generation, API versioning, hashed identifiers, RBAC and localisation, wired together and kept in step.

The cost is the same in kind. You get conventions you did not choose, a directory layout you must learn, and a dependency on the maintainers' upgrade cadence. The v13 restructure is the concrete example: a lot of files moved, and a project that took the shortcut of `create-project` will need to follow the upgrade guide rather than pull a change through Composer.

There is a second, smaller surprise worth naming. The release notes for v13 compare both `apiato/apiato` and `apiato/core`, and the README's core package is a separate repository. The template and the framework packages are versioned independently, which is why a Core namespace change can land alongside an Apiato file restructure. Reading the Core changelog too is part of reading a version bump properly.

The repository also carries an `AGENTS.md` and a `.ddev/` directory, so there is local environment tooling and written guidance for automated contributors. Both are recent additions to what was once a plain Laravel skeleton.

## Conclusion

Apiato makes sense when a team wants a working API skeleton on day one rather than a week of Laravel wiring, and when it can accept a specific set of conventions about layers, containers and generated files. It is a poor fit if you would rather own a minimal Laravel application, because the whole point is that the framework's own scaffolding is the product. Check three things before committing: that PHP 8.2 and the Laravel version in the v13 upgrade guide match your target environment, whether you want hashed identifiers in API responses at all, and how much of `app/Ship` you would have to delete. Run `composer create-project apiato/apiato`, read the upgrade guide for the version you would pin, and only then look at the feature list on apiato.io.

## FAQ

### What is Apiato?

Apiato is a PHP framework and starter project built on top of Laravel, using the Porto SAP architectural pattern. It is installed with `composer create-project apiato/apiato`, which means you start from a complete application skeleton rather than adding a library to something you already have.

### What does Apiato add on top of Laravel?

The README lists code generators, documentation generators, API versioning, OAuth 2.0 authentication, role-based access control, pagination, caching, ETag support, a performance profiler, localisation, social authentication, test helpers and hashed identifiers. It also ships static analysis configuration for PHPStan and Psalm, PHPUnit, PHP CS Fixer and a Vite plus Tailwind frontend build.

### Which PHP and Laravel versions does the current Apiato release require?

The v13.0.0 release notes raised the minimum PHP version to `^8.2` and the minimum Laravel version to `^11.23`, and v13.1.0 added support for Laravel 12. The upgrade guide linked from the release notes documents the breaking changes, including the `apiato:generate` command being renamed to `apiato:make`.

## Sources

- [apiato/apiato on GitHub](https://github.com/apiato/apiato)
- [License: MIT](https://github.com/apiato/apiato/blob/13.x/LICENSE)
- [Project website](http://apiato.io)
- [README](https://github.com/apiato/apiato/blob/13.x/README.md)
- [Releases](https://github.com/apiato/apiato/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/apiato-apiato