Smart Enviro Backend is structured around three distinct layers that never share authentication mechanisms. At the hardware layer, ESP32 microcontrollers authenticate exclusively with a staticDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/GaelCeballos/Smart_Enviro_Backend/llms.txt
Use this file to discover all available pages before exploring further.
device_token stored in the devices table — no session cookies, no bearer headers. In the middle sits the Laravel 11 API server (PHP 8.4 + Laravel Sanctum), which routes requests, enforces access control, and persists all telemetry to MySQL. At the top, mobile apps and web dashboards authenticate with Sanctum Bearer tokens obtained at login, then call the full suite of device-management and sensor-history endpoints.
System Components
| Component | Role |
|---|---|
| ESP32 Devices | Authenticate with device_token query param; call GET /api/device/sync to receive commands and config; push readings via POST /api/sensor-data |
| Laravel API | PHP 8.4 application handling routing, auth:sanctum middleware, business logic via controllers, and persistence to MySQL |
| Mobile/Web Client | Authenticates with a Sanctum Bearer token; discovers and claims unowned devices; toggles actuator states; queries sensor history |
| MySQL 8.x | Persists all application data across six tables: users, devices, device_properties, sensor_types, sensor_data, device_logs |
Request Flow
Mobile/Web Client Flow
Register
Client calls
POST /api/register with name, email, password, and password_confirmation. Returns 201 Created on success — no token is issued at registration.Login
Client calls
POST /api/login with email and password. On success the API creates a Sanctum token, stores its plain-text value in users.current_token, and returns it in the response body.Call Protected Endpoints
Every subsequent request includes the token as
Authorization: Bearer {token}. The auth:sanctum middleware validates the token and resolves the authenticated user.ESP32 Device Flow
Boot and Sync
On startup the device calls
GET /api/device/sync?device_token={token}. The API looks up the device by its token, verifies it is active, updates last_seen_at and is_online, then returns the current command and any config properties the device should apply.Push Sensor Readings
At each measurement interval the device posts to
POST /api/sensor-data with device_token in the request body alongside the sensor readings. The API validates the token, resolves the device, and writes one sensor_data row per reading.Receive Updated Control State
Both the sync response (
command + config) and the sensor-data store response (device_control block) return the latest commanded state (ON, OFF, or STANDBY) so the ESP32 can update its behaviour without a persistent connection. The sync response includes the full config key-value map of device properties; the sensor-data response includes derived control flags such as auto_water and humidity_threshold.Route Groups
There are three distinct route groups defined inroutes/api.php:
1. Public Routes — No Authentication Required
| Method | URI | Handler |
|---|---|---|
POST | /api/login | AuthController@login |
POST | /api/register | AuthController@register |
GET | /api/device/sync | DeviceSyncController@sync |
device/sync relies on the device_token query parameter for its own device-level authorization rather than Sanctum middleware.
2. Protected Routes — auth:sanctum Middleware
| Method | URI | Handler |
|---|---|---|
GET | /api/my-devices | UserDeviceController@index |
GET | /api/my-devices/{id} | UserDeviceController@show |
POST | /api/my-devices/{id}/toggle | UserDeviceController@toggleState |
PUT | /api/my-devices/{id}/properties | UserDeviceController@updateProperty |
GET | /api/devices/available | UserDeviceController@listAvailable |
POST | /api/devices/{id}/add | UserDeviceController@addDevice |
GET | /api/sensor-data/history | SensorDataController@getHistory |
DELETE | /api/logout | AuthController@logout |
GET | /api/user | Closure — returns authenticated user |
GET /api/sensor-data/history is declared before the apiResource registration so that Laravel’s router matches it as a named route rather than treating history as a {sensor_data} wildcard segment.3. API Resource Routes — sensor-data
The apiResource registration for sensor-data excludes the update method, leaving four actions:
| Method | URI | Handler | Auth |
|---|---|---|---|
GET | /api/sensor-data | SensorDataController@index | None |
POST | /api/sensor-data | SensorDataController@store | device_token in body |
GET | /api/sensor-data/{sensor_data} | SensorDataController@show | None |
DELETE | /api/sensor-data/{sensor_data} | SensorDataController@destroy | None |
Single-Session Enforcement
Smart Enviro Backend allows only one active session per user account at any given time. This is enforced through thecurrent_token column added to the users table:
- Login — after issuing a new Sanctum token the API saves its plain-text value to
users.current_token. Ifcurrent_tokenis already non-null when a login request arrives, the API returns409 Conflictwith{"status": "error", "message": "Cuenta en uso en otro dispositivo"}and does not issue a new token. - Logout — the API deletes the Sanctum token record and sets
current_tokenback tonull, freeing the account for a fresh login.
Data Model
Full schema reference for all six MySQL tables, column types, constraints, and Eloquent relationships.
Authentication
How Sanctum Bearer tokens and device_token strings work, with curl examples for every auth flow.