Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/lffiesco-svg/gastromovil/llms.txt

Use this file to discover all available pages before exploring further.

GastroMóvil’s REST API uses two authentication mechanisms side-by-side: JWT Bearer tokens (via djangorestframework-simplejwt) for programmatic API access, and Django session cookies for the server-rendered web UI. Both are listed in DEFAULT_AUTHENTICATION_CLASSES; the framework tries SessionAuthentication first, then falls back to JWTAuthentication. For API clients, JWT is the recommended approach.

​
JWT Configuration

The following settings govern token behavior in GastroMóvil:
SettingValue
ACCESS_TOKEN_LIFETIME60 minutes
AUTH_HEADER_TYPESBearer
Access tokens expire after one hour. Use the refresh endpoint to obtain a new access token without re-entering credentials.

​
Obtain Tokens

Send the user’s email address as the username field together with the account password. GastroMóvil uses an EmailBackend, so the login identifier is always the email address even though the field is named username in the JWT payload. POST /api/login/
​
username
string
required
The user’s email address. GastroMóvil’s EmailBackend authenticates by email, not by a separate username string.
​
password
string
required
The account password in plain text over HTTPS.
curl -s -X POST https://gastromovil.online/api/login/ \
  -H "Content-Type: application/json" \
  -d '{"username": "usuario@ejemplo.com", "password": "micontraseña"}'
Success — 200 OK 
{
  "access": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "refresh": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
}
​
access
string
Short-lived JWT access token. Valid for 60 minutes. Include this in the Authorization header for every protected request.
​
refresh
string
Long-lived JWT refresh token. Use it at POST /api/refresh/ to obtain a new access token.
Error — 401 Unauthorized 
{
  "detail": "No active account found with the given credentials"
}

​
Use the Access Token

Add the access token as a Bearer value in the Authorization header on every request that requires authentication. 
curl -s https://gastromovil.online/api/pedidos/ \
  -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
Omitting the header or sending an expired token on a protected endpoint returns 401 Unauthorized with {"detail": "Authentication credentials were not provided."}.

​
Refresh the Access Token

When the access token expires, exchange the refresh token for a new one without asking the user to log in again. POST /api/refresh/
​
refresh
string
required
The refresh token received from POST /api/login/.
curl -s -X POST https://gastromovil.online/api/refresh/ \
  -H "Content-Type: application/json" \
  -d '{"refresh": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."}'
Success — 200 OK 
{
  "access": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
}
If the refresh token has expired or been tampered with, the endpoint returns 401 Unauthorized. The user must authenticate again at POST /api/login/.

​
Django Session Authentication

The browser-facing web UI authenticates through Django’s standard session mechanism. A successful POST to POST /usuarios/login/ (form fields: email, password) creates a session cookie that the browser attaches automatically to subsequent requests. Session cookies expire after 30 minutes of inactivity (SESSION_COOKIE_AGE = 1800) and are discarded when the browser tab is closed (SESSION_EXPIRE_AT_BROWSER_CLOSE = True).
API clients should always use JWT tokens. Session authentication is intended for the HTML interface and requires CSRF tokens on mutating requests, which adds complexity for non-browser clients.

​
Authentication Class Order

GastroMóvil’s REST_FRAMEWORK setting registers authentication backends in this order: 
REST_FRAMEWORK = {
    "DEFAULT_AUTHENTICATION_CLASSES": (
        "rest_framework.authentication.SessionAuthentication",
        "rest_framework_simplejwt.authentication.JWTAuthentication",
    ),
}
When a request carries a valid session cookie the framework resolves the user from the session without ever inspecting the Authorization header. When there is no session, it looks for a Bearer token.

​
Ownership Requirement

Most restaurant-facing API endpoints enforce an additional ownership check beyond authentication. Resources are scoped to the currently authenticated user’s restaurant — for example, product and order queries are filtered by restaurante__propietario=request.user. A valid token for a user who does not own the requested restaurant returns 404 Not Found, not 403 Forbidden.

Build docs developers (and LLMs) love

Get started for freeTalk to us