Your API is running.
This page confirms the server booted successfully, all core services are active, and every registered endpoint is reachable.
You are ready to test endpoints or build new ones.
Each section below is labeled and explained — so if you are ever asked what something means, you can point directly to it.
01 — Runtime Environment
These four values confirm how and where Django is currently running. They come from your settings.py and .env file. If any of these were misconfigured, the server would not have started at all.
Boot Sequence
COMPLETE
Django loaded without errors. All apps, middleware, and URL routes are registered and ready.
Server Status
ONLINE
The process is running and actively accepting incoming HTTP requests right now.
Environment
PRODUCTION
DEBUG is False. Errors are not shown to clients. Production settings and security rules apply.
Timezone
Africa / DSM
All server timestamps use Africa/Dar_es_Salaam. This affects logs, scheduled tasks, and database timestamps.
02 — Core Services
These are the internal components your API depends on. Each one must be active for requests to be handled correctly. Think of them as the building blocks — the layers that sit on top of each other to make the API work.
Django Core
The base web framework. Handles URL routing, settings, middleware, and the application lifecycle. Everything else in this list depends on this being active first.
ACTIVE
REST Framework
Django REST Framework (DRF) — the layer that turns Django views into a proper API. It handles serializers, viewsets, request/response formatting, and permission classes.
READY
JWT Auth System
Simple JWT is loaded and configured. This is what issues tokens when users log in and validates them on every protected request. Without this, no authentication would be possible.
ENABLED
CORS Gateway
Cross-Origin Resource Sharing controls which frontend domains are allowed to call this API. Without correct CORS configuration, your browser would block every request from the frontend — even if the API itself is fine.
OPERATIONAL
Database Link
Django opened a connection to the database successfully. All models and queries are available. If this were down, no data could be read or written — every API call that touches data would fail.
CONNECTED
03 — Authentication Method
This explains how the API verifies identity on every request. Understanding this is essential when testing endpoints — protected routes return 401 Unauthorized if the request does not carry valid credentials in the right form.
JWT tokens stored in HTTP-only cookies — with Authorization header fallback
When a user logs in via /api/v1/auth/token/, the server issues a JWT (JSON Web Token) and sends it back
as a Set-Cookie response header. The browser stores this automatically and sends it with every future request —
your JavaScript never reads or touches the token. The custom class JWTCookieAuthentication reads the
access_token cookie on each request. If no cookie exists, it falls back to the Authorization
header — which is how Postman, mobile apps, and server-to-server calls authenticate.
HttpOnly Cookie
The token lives in a cookie that JavaScript cannot access. Even if malicious script runs on the page, it cannot read or steal the token. This is the primary XSS defence.
ACTIVE
Secure = True
The cookie is only transmitted over HTTPS. It will never travel over an unencrypted connection. Confirmed by SESSION_COOKIE_SECURE=True in your production environment file.
ENFORCED
SameSite = None
Your frontend (ujenzisolving.co.tz) and API (api.ujenzisolving.co.tz) live on different subdomains —
the browser classifies this as cross-site. SameSite=None is the only option that allows the cookie to be sent across subdomains.
But browsers enforce a hard rule: SameSite=None is silently discarded if Secure is not also True.
No error is shown — login returns 200, but the cookie is never stored, and every next request returns 401.
This is why Secure=True above is non-negotiable.
SET
CSRF Protection
POST, PUT, and DELETE requests require a valid CSRF token. This prevents a third-party site from tricking a logged-in user's browser into making unwanted API calls on their behalf.
ENFORCED
Silent Token Refresh
Access tokens expire after a short window. Before expiry, the frontend calls /accounts/refresh/ — it reads the refresh token from its own cookie and issues a new access token cookie. The user never experiences a forced logout.
CONFIGURED
Frontend Requirement
Every API call from React or Nuxt must include credentials: 'include' (fetch) or withCredentials: true (Axios). Without this line, the browser will not attach the cookie — the request arrives unauthenticated.
REQUIRED
⚠
One gap to be aware of: The SIMPLE_JWT['AUTH_COOKIE_SECURE'] flag is read from your env var once at server startup —
it is not covered by the if not DEBUG block that overrides Django's session and CSRF cookie settings.
In production this is fine because your env has SESSION_COOKIE_SECURE=True. But if that var were ever
missing or wrong, the JWT cookie would silently break while session and CSRF cookies remained protected.
Keep this in mind the next time you need to debug a 401 that appears right after login.
04 — Registered Endpoints
These are all the URL routes this API currently exposes. A 200 OK next to each one means the route is registered, reachable, and returned a valid response. This is the list you will work through during endpoint testing.
/api/v1/auth
Login, logout, token issue, refresh, and verify. The entry point for any authentication flow. Test this first — everything else requires a valid token from here.
200 OK
/api/v1/organizations
Create, read, update, and delete organizations. This is the top-level entity in your system — surveys, users, and reports all belong to an organization.
200 OK
/api/v1/surveys
Manage surveys. Organizations build and publish surveys here. The core resource of the platform.
200 OK
/api/v1/responses
Submitted answers to surveys. Users post their responses here. This data feeds directly into reports and analytics.
200 OK
/api/v1/reports
Aggregated results built from survey responses. Read-heavy — typically consumed by dashboards to display charts and summaries.
200 OK
/api/v1/notifications
System alerts for users — new responses, status changes, or updates. Can be polled on an interval or pushed via websocket depending on your implementation.
200 OK