API — Configuration
How settings and environment variables are wired for the Django API.
Settings load order
config/settings.py— base project settings- Optional
config/local_settings.py— imported withfrom .local_settings import *inside atry/except ImportError - Environment /
.envvalues used where settings read them (see.env.example)
local_settings.py is the usual place for local DEBUG, SECRET_KEY, and DATABASES. It must stay out of git.
local_settings.py (local)
Minimal example used in Installation:
DEBUG = True
SECRET_KEY = "replace-with-a-long-random-string"
DATABASES = {
"default": {
"ENGINE": "django.db.backends.mysql",
"NAME": "resa_database",
"USER": "root",
"PASSWORD": "yourpassword",
"HOST": "127.0.0.1",
"PORT": "3306",
}
}
.env / deployment variables
Copy from .env.example in the api repo. Typical keys:
| Variable | Purpose |
|---|---|
SECRET_KEY |
Django secret |
DJANGO_DEBUG |
Debug flag |
ALLOWED_HOSTS |
Comma-separated hosts |
CORS_ALLOWED_ORIGINS |
Staff/Customer origins (e.g. http://localhost:5173) |
CORS_ALLOW_ALL_ORIGINS |
Optional loose CORS in dev |
DB_NAME / DB_USER / DB_PASSWORD / DB_HOST / DB_PORT |
Database |
DB_SSLMODE |
SSL mode (e.g. DISABLED locally) |
VAPID_PUBLIC_KEY |
Optional Web Push |
Exact consumption lives in config/settings.py — treat .env.example as the checklist when deploying.
CORS
Frontends on another origin (Vite on 5173) need their origin listed in CORS_ALLOWED_ORIGINS, or a deliberate dev override. Wrong CORS usually shows up as failed login/API calls from Staff or Customer.
URL surface
| Path | Use |
|---|---|
/api/… |
Application HTTP API |
/api/auth/… |
Staff auth |
/django-admin/ |
Django admin |