Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/CodexaCP/DG_WEB/llms.txt

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

The Dragon Guard WMS authentication flow is built on JWT tokens issued by the POST /api/Auth/login endpoint. After a successful login, the frontend stores the token in session storage and attaches it as a Bearer header on every subsequent API request. Tenant users must have exactly one operational company in the response; the platform stores that company’s identifier as active_company_id in sessionStorage to scope all data queries. The SUPERADMIN_SUPREMO role is exempt from this requirement.

Login


POST /api/Auth/login
Content-Type: application/json

Request body

email
string
required
The user’s registered email address.
password
string
required
The user’s account password. Transmitted over HTTPS only.
Example request
{
  "email": "[email protected]",
  "password": "s3cur3P@ss!"
}

Response

A successful 200 OK returns a JSON object with the token and user metadata.
token
string
Signed JWT token. Pass this value as Authorization: Bearer {token} on all subsequent requests.
userId
number
Internal numeric identifier for the authenticated user.
email
string
The authenticated user’s email address, echoed back from the request.
fullName
string
Display name of the authenticated user.
companies
array
List of companies the user is associated with. Tenant users must receive exactly one operational company; this value is used to set active_company_id in sessionStorage.
Example response
{
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "userId": 42,
  "email": "[email protected]",
  "fullName": "Ana García",
  "companies": [
    { "id": 7, "name": "MAS Logistics SRL", "isOperational": true }
  ]
}

Token usage

All endpoints in Dragon Guard WMS (except /api/Auth/login itself) require a valid JWT token. Include it in the Authorization header of every request:
GET /api/ReceivingHeaders?companyId=7
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Tokens are short-lived. When the frontend receives a 401 Unauthorized response, it must redirect the user to the login page and clear any stored session data.

Session storage keys

After a successful login, the Angular frontend writes the following values to sessionStorage:
KeyValue
tokenThe raw JWT string from response.token
userIdNumeric user ID from response.userId
active_company_idID of the single operational company (tenant users only)
fullNameUser display name for the UI header
Tenant user rule: If response.companies does not contain exactly one operational company, the login must be rejected on the client side with an appropriate user-facing error. The active_company_id must not be set to an ambiguous value.
SUPERADMIN_SUPREMO accounts are not required to have active_company_id set. These accounts access cross-tenant endpoints under /api/supreme/ and operate without a single company scope.

Multi-company rule for tenant users

companies.filter(c => c.isOperational === true).length === 1
The frontend enforces the above constraint at login time. If a tenant user’s account is associated with zero operational companies or more than one, the session cannot be established and the user is shown an error message prompting them to contact their administrator.

Document sequence (informational)

GET /api/document-sequence?companyId={companyId}
Authorization: Bearer {token}
This endpoint returns the next visual document number for a given company and document type. It is used by the frontend solely to display a preview of the upcoming document number in creation forms.
The number returned by GET /api/document-sequence is not authoritative. The backend generates and persists the definitive document number within the creation transaction. Never use the sequence value as a primary key or reference in subsequent API calls.

Error codes

HTTP StatusMeaning
400Validation error — missing or malformed fields in the request body
401Invalid credentials or expired/missing token
500Internal server error — contact the backend team
Example 400 response
{
  "errors": [
    { "field": "email", "message": "The email field is required." }
  ]
}

Build docs developers (and LLMs) love