The API uses three route prefixes based on who's acting and what they're acting on.
/auth covers authentication flows. Guest actions like login, registration, and password reset live here, along with authenticated session actions like logout and token refresh. The split is by middleware: guest routes get throttled, authenticated routes require Sanctum.
/account is for the current user managing their own stuff. Profile updates, password changes, avatar uploads, bookmarks, categories. No ID needed since the user is always inferred from the auth token.
/admin is for admin users managing any resource. These mirror the structure of regular endpoints but with elevated access, different validation, and richer response payloads. An admin middleware on the group acts as a safety net, requiring admin or super role before any route-specific policy checks run.
/users/me?Treating "me" as a special case of /users/{id} muddies the controller logic. The current user's own account operations have different validation, different authorization, and often different response shapes than an admin managing arbitrary users. Separate route groups keep that clean.
Controllers are organized into three namespaces matching the route prefixes. Auth controllers live under Controllers/Auth/, account controllers under Controllers/Account/, admin controllers under Controllers/Admin/.
The same pattern applies to form requests and resources. Requests/Account/Profile/UpdateRequest mirrors Requests/Admin/User/UpdateRequest. Tests follow the same structure: tests/Feature/Account/Profile/UpdateTest.php.
If an admin endpoint and an /account endpoint do the same underlying work (e.g., updating a user record), extract that into a service class. Don't duplicate the logic across controllers, but also don't create service classes preemptively. Wait until two controllers actually share behavior.