Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/fatelessdev/translogiX/llms.txt

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

TranslogiX uses a role-based access control system to determine what each user can see and do. Every user account is assigned one of four roles, and that role controls which dashboard section they land on after login, which API endpoints they can call, and what data they are permitted to view or modify.

​
The four roles

ADMIN

Full access to all platform data. Can manage users, transporters, vehicles, routes, and shipments across the entire system. Not scoped to any single transporter.

TRANSPORTER

Access scoped to their own transporter entity. Can manage vehicles and shipments that belong to their linked transporter account. Must have a transporterId set by an admin.

DRIVER

Routed to the /driver section of the application. Intended for drivers operating under a transporter. Specific driver-level permissions are enforced at the route level.

CUSTOMER

The default role assigned to all new accounts. Routed to the /customer section. Can track shipments and view information relevant to their own orders.

​
Role capabilities

CapabilityADMINTRANSPORTERDRIVERCUSTOMER
View all shipmentsYesOwn only——
Create shipmentsYesOwn only——
Update shipment statusYesOwn only——
Manage vehiclesYesOwn only——
Manage routesYesNo——
Manage transportersYesNo——
Manage users / assign rolesYesNoNoNo
The DRIVER and CUSTOMER dashboard capabilities depend on their respective route implementations. The table above reflects the API-layer permissions enforced by the backend.

​
Role-based routing

After a user signs in, the root page (/) reads the session and immediately redirects to the section that matches their role:
RoleRedirect destination
ADMIN/admin
TRANSPORTER/transporter
DRIVER/driver
CUSTOMER/customer
If a user with a session tries to access a section that does not belong to their role — for example, a CUSTOMER visiting /admin — the middleware intercepts the request and redirects them back to their own home route. Unauthenticated users are always redirected to /login. The only publicly accessible paths are /login, /track (public shipment tracking), and /api/auth/*.

​
TRANSPORTER data scoping

TRANSPORTER users are linked to a specific transporter entity via the transporterId field on their user record. This field is set by an ADMIN and cannot be self-assigned. When a TRANSPORTER calls the API:
  • All list queries are automatically filtered to return only records belonging to their transporterId.
  • Attempts to read or modify a resource owned by a different transporter return a 403 Forbidden response.
  • ADMIN users are never filtered — they see and can modify all records regardless of transporter.
// From lib/auth/api-utils.ts
// TRANSPORTER: returns their transporterId (force-filter)
// ADMIN: returns null (no filter, sees all)
export async function requireTransporterScope(request: NextRequest) { ... }
A TRANSPORTER user account without a linked transporterId will receive a 403 No transporter account linked error on any scoped endpoint. An ADMIN must link the transporter entity to the user account before the user can access the platform.

​
How roles are assigned

Roles are assigned exclusively by ADMIN users. There is no self-registration path for the ADMIN, TRANSPORTER, or DRIVER roles. New accounts default to the CUSTOMER role and must be promoted by an admin. 
// From lib/db/schema.ts
role: userRoleEnum("role").default("CUSTOMER").notNull(),

​
API authentication utilities

The backend exposes three composable helpers in lib/auth/api-utils.ts for enforcing roles inside API route handlers:
HelperWhat it does
requireSessionReturns 401 if the request has no valid session.
requireRole(request, roles[])Returns 401 with no session, 403 if the user’s role is not in the allowed list.
requireTransporterScopeAllows ADMIN (unfiltered) and TRANSPORTER (filtered to their transporterId). Returns 403 for all other roles.
verifyOwnershipChecks that a TRANSPORTER user owns a specific resource. ADMIN always passes.

Build docs developers (and LLMs) love

Get started for freeTalk to us