Laravel Image Manipulation API

The problem

An image manipulation endpoint looks simple until it becomes multi-tenant. Once every user owns albums and images, the API has to answer a harder question on every single request: does this token belong to someone allowed to touch this specific record. Getting that wrong is not a bug that shows up in testing, it is a data leak. On top of that, an image can arrive two different ways, as an uploaded file or as a remote URL, and both paths have to end in the same validated state.

Approach

• Authentication uses Laravel Sanctum tokens, with every write route behind the auth middleware group and a versioned v1 prefix so the contract can evolve without breaking clients.
• Ownership is checked explicitly: before an image is attached to an album, the album is loaded and compared against the authenticated user, returning 403 rather than silently succeeding.
• The resize endpoint accepts either an uploaded file or a remote URL, normalizing both into the same stored record with its original name, path and manipulation metadata.
• Each upload lands in its own randomly named directory, so files cannot collide or be guessed by iterating predictable paths.
• Request validation lives in a dedicated form request class rather than inside the controller, keeping the rules declarative and reusable.
• The manipulation parameters are persisted alongside the image, so every derived image records how it was produced.

What it proves

• Multi-tenant API where album access is verified per request, not assumed from the token.
• Two input paths, file upload and remote URL, converge on one validated record shape.
• Interactive OpenAPI documentation published and reachable on its own domain.
• Token authentication with versioned routes, ready to evolve without breaking clients.