Skip to main content

Documentation Index

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

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

Dragon Guard WMS API uses JWT Bearer authentication for all protected endpoints. Every request to an operational controller must present a valid token issued by the Dragon Guard auth service. The API exposes two distinct authentication flows depending on the type of actor: a standard email/password flow for back-office users and a GrupoMAS delegated handheld flow for warehouse device operators.

​
Authentication flows

Standard Login

Back-office users authenticate with their email address and BCrypt-verified password. The API issues a Dragon Guard JWT that carries tenant scope and role claims. Suitable for supervisors, administrators, and any user who logs in through the web interface.

Handheld Login

Warehouse operators on GrupoMAS-integrated tenants authenticate their credentials directly against the MAS ERP. Dragon Guard validates the device, delegates credential verification to MAS, and then issues its own JWT for the session. No local auth.Users row is created for these operators.

​
How authentication works

1

Call the login endpoint

Send a POST request to the appropriate login endpoint with the required credentials. The two endpoints are:
  • POST /api/auth/login — standard email/password
  • POST /api/auth/grupomas-handheld-login — GrupoMAS delegated handheld
Both endpoints are public and do not require an existing token.
2

Receive the JWT

A successful response includes a signed JWT in the token field along with user metadata. Tokens are HMAC SHA-256 signed and carry an expiry set by Jwt:ExpiresInMinutes in the server configuration.
3

Attach the token to subsequent requests

Pass the token as a Bearer token in the Authorization header on every protected request:
Authorization: Bearer <token>

​
Company context

Every protected request must resolve to a specific tenant. Dragon Guard uses the following resolution order (first match wins):
  1. companyId query parameter
  2. X-Company-Id request header
  3. companyId claim embedded in the JWT
All three paths are validated against the company_access claims in the token. A request that supplies a companyId the token does not grant access to is rejected immediately — the API never trusts an arbitrary company identifier without checking token claims first.
SUPERADMIN_SUPREMO accounts bypass tenant access checks and have no company_access claims. All other users must resolve to a company present in their token.

​
Tenant isolation

Dragon Guard enforces strict single-tenant boundaries for non-supreme users:
  • A user belongs to exactly one tenant. Assigning the same user to a second tenant is rejected in AuthRepository.AssignUserToCompanyAsync regardless of how the assignment is triggered (self-registration, admin creation, or supreme admin creation).
  • If historical data leaves a user assigned to more than one tenant, login is blocked with auth.userAssignedToOtherTenant until the data is corrected. This prevents any possibility of cross-tenant token scope leakage.
  • SUPERADMIN_SUPREMO is a global account with no tenant context. Operational re-assignment back into a tenant is also rejected for supreme accounts.

​
Roles

Dragon Guard defines the following role codes:
Role codeScopeDescription
OPERATORTenantDefault role for self-registered and handheld users.
SUPERVISORTenantElevated warehouse operations access.
ADMINTenantFull tenant administration.
SUPERADMIN_SUPREMOGlobalGlobal SaaS administration. No tenant context. Full platform access.
Role resolution at request time is performed by ApiControllerBase.Role. When company_role claims are present the effective role for the resolved company is used. Legacy tokens without company_role fall back to the global role claim.

​
Inactive tenant enforcement

Tenant active status is checked in two independent layers:
  1. At login — POST /api/auth/login queries dbo.Companies and rejects the login with 403 auth.companyInactive when the tenant’s IsActive flag is false or Status is not "Active".
  2. Per request — authenticated requests to operational endpoints re-check tenant active status so that a user cannot continue operating with a previously issued token after a supreme admin deactivates the company.
Deactivating a tenant in Dragon Guard takes effect immediately for new login attempts. Tokens issued before deactivation are also invalidated at the per-request middleware layer — no grace period is provided.

​
Further reading

  • Login (email/password) — full endpoint reference for POST /api/auth/login, registration, and password management
  • Handheld Login — GrupoMAS delegated login flow for warehouse devices
  • JWT Claims — complete claim reference and company context resolution details

Build docs developers (and LLMs) love

Get started for freeTalk to us