iLeben API: Token Authentication and Origin Validation Guide

The iLeben API enforces a two-layer authentication system. The first layer is Laravel Sanctum — every protected request must carry a valid Bearer token issued by POST /api/v1/login. The second layer is the custom token.origin middleware, which validates that the request’s Origin, Referer, or X-Authorized-Url header matches the authorized_url field stored on the token. Both layers must pass before the API processes the request. Catalog endpoints require only token.origin; endpoints in the checkout, payment, and reservation groups also require a valid Sanctum session (auth:sanctum).

Obtaining a Token

Send a POST request to /api/v1/login with a JSON body containing the user’s email and password. On success, the API returns a user object and a plain-text token string that you use as a Bearer token on subsequent requests.

string

required

The user’s registered email address.

password

string

required

The user’s password.

curl -X POST "https://tu-dominio.com/api/v1/login" \
  -H "Content-Type: application/json" \
  -d '{"email":"admin@dominio.com","password":"secret"}'

A successful response returns HTTP 200 with the following shape:

{
  "user": {
    "id": 1,
    "name": "Admin",
    "email": "admin@dominio.com"
  },
  "token": "1|token-plano-sanctum"
}

user

object

The authenticated user record (id, name, email).

token

string

The plain-text Sanctum token to attach as Authorization: Bearer <token> on every subsequent request. Store this securely — it is not shown again.

Never expose the Bearer token in client-side JavaScript, public source repositories, or browser localStorage. Tokens have no automatic rotation — if one is leaked, revoke it immediately from the Filament admin panel and issue a new one.

Using the Token

Attach the token on every API call that requires authentication using the standard HTTP Authorization header:

Authorization: Bearer <token>

The full token string including the numeric prefix (e.g. 1|abc...) must be sent exactly as returned by the login endpoint. Here is an example request that fetches the authenticated user’s profile:

curl "https://tu-dominio.com/api/v1/me" \
  -H "Authorization: Bearer 1|token-plano-sanctum" \
  -H "Origin: https://frontend.cliente.com"

The `token.origin` Middleware

In addition to the Bearer token, most API endpoints validate the origin of the request against the authorized_url stored on the token. This is enforced by the EnsureTokenOriginIsAuthorized middleware, registered as token.origin. The middleware reads the request origin from the first non-empty header in this priority order:

Header	Description
`Origin`	Standard browser origin header, sent automatically by browsers on cross-origin requests
`Referer`	Full referring URL; the middleware normalizes it to scheme + host before comparison
`X-Authorized-Url`	Custom header for server-to-server clients that cannot set `Origin`

The resolved origin is normalized to scheme://host[:port] (lowercased, no trailing slash) before being compared to the token’s authorized_url. If the token has no authorized_url set, the origin check is skipped and any origin is accepted.

Catalog endpoints (/api/v1/proyectos, /api/v1/plantas, and related routes) are protected by token.origin only — they do not require auth:sanctum. A valid Bearer token with a matching origin header is sufficient to read the full real estate catalog without a user login session.

The following cURL example shows both the Authorization and Origin headers for a catalog request:

curl "https://tu-dominio.com/api/v1/plantas?proyecto_id=3&disponible=1" \
  -H "Authorization: Bearer 1|token-plano-sanctum" \
  -H "Origin: https://frontend.cliente.com"

For server-to-server integrations that cannot set the Origin header automatically, use X-Authorized-Url instead:

curl "https://tu-dominio.com/api/v1/plantas" \
  -H "Authorization: Bearer 1|token-plano-sanctum" \
  -H "X-Authorized-Url: https://frontend.cliente.com"

Token Model Details

Tokens are stored in the personal_access_tokens table using a custom PersonalAccessToken model that extends Laravel Sanctum’s base class. Two additional columns are relevant to the middleware:

Column	Type	Behaviour
`authorized_url`	`string\|null`	If set, every `token.origin`-protected request must present a matching origin. If `null`, the origin check is skipped.
`expires_at`	`datetime\|null`	If set and in the past, the token is treated as invalid and returns `401`. If `null`, the token never expires.

The model exposes an active scope that filters out expired tokens:

PersonalAccessToken::active()->find($id);
// WHERE (expires_at IS NULL OR expires_at > NOW())

Error Reference

HTTP Status	Message	Cause
`401`	`Token de acceso requerido.`	No `Authorization: Bearer` header was sent
`401`	`Token de acceso inválido o expirado.`	The token does not exist, has been revoked, or its `expires_at` is in the past
`403`	`La URL de origen no está autorizada para este token.`	The resolved origin from `Origin` / `Referer` / `X-Authorized-Url` does not match the token’s `authorized_url`

If your frontend receives a 403 with a valid token, compare the Origin or Referer your client is sending against the authorized_url configured on the token in the Filament admin panel. The comparison is exact after normalization — a mismatch in protocol (http vs https) or a missing/extra port will cause a 403.

Token Management

API tokens are managed from the Filament admin panel under the API Tokens resource at /admin/api-tokens. From there, administrators can:

Create new tokens and assign an authorized_url and optional expires_at
Inspect the last_used_at timestamp to audit active tokens
Delete tokens to revoke access immediately

To revoke the current token programmatically (for example, on user logout), call:

curl -X POST "https://tu-dominio.com/api/v1/logout" \
  -H "Authorization: Bearer 1|token-plano-sanctum" \
  -H "Origin: https://frontend.cliente.com"

This deletes the token from the database. Any subsequent request using that token string will receive a 401 Token de acceso inválido o expirado. response.

Bearer Token and `site-config`

The GET /api/v1/site-config endpoint is public, but the response payload can include additional fields when a valid Bearer token is present on the request. Including an Authorization: Bearer <token> header signals to the backend that the caller is an authorized client, allowing it to surface data that would otherwise be omitted from anonymous responses.

curl "https://tu-dominio.com/api/v1/site-config" \
  -H "Authorization: Bearer 1|token-plano-sanctum"

The exact set of extra fields depends on the site configuration. If you are building an authorized frontend integration and require the full config payload, include the Bearer token on every site-config request.

Overview

Public Endpoints

Authenticated Endpoints

iLeben API: Token Authentication and Origin Validation Guide

Obtaining a Token

Using the Token

The `token.origin` Middleware

Token Model Details

Error Reference

Token Management

Bearer Token and `site-config`

Build docs developers (and LLMs) love

Overview

Public Endpoints

Authenticated Endpoints

Documentation Index

​Obtaining a Token

​Using the Token

​The token.origin Middleware

​Token Model Details

​Error Reference

​Token Management

​Bearer Token and site-config

Build docs developers (and LLMs) love

Obtaining a Token

Using the Token

The `token.origin` Middleware

Token Model Details

Error Reference

Token Management

Bearer Token and `site-config`