Token types
There are two principal token types, distinguished by thetype claim inside
the JWT:
| Type | Obtained from | Used for |
|---|---|---|
admin | POST /api/v1/auth/login (email + password) | Bookkeeper admin endpoints (/api/v1/admin/*) |
employee | POST /api/v1/auth/employee/verify (phone + PIN) | Employee endpoints (/api/v1/employee/*) |
A
client token type also exists in the auth layer, but the documented
/api/v1 endpoints only require admin or employee tokens.HS256 and expire after JWT_EXPIRES_IN (default
7 days). The token payload includes userId, type, and — depending on the
type — bookkeeperOrgId, companyId, and email.
Sending the token
Send the JWT in theAuthorization header as a bearer token:
Cookie fallback
The login endpoints also set anhttpOnly cookie named auth-token (7-day
max-age, SameSite=Lax, Secure in production). If no Authorization header
is present, the server falls back to this cookie. Browser-based clients on the
same origin are therefore authenticated automatically; API integrations should
prefer the explicit Authorization header.
The header takes priority over the cookie when both are present.
Authorization rules
Endpoints enforce the required token type. Requesting anadmin endpoint with
an employee token (or vice-versa) is rejected.
No
Authorization header and no auth-token cookie, or the token is invalid
or expired.Token is valid but its
type claim does not match the endpoint’s required
type (Access denied. Required role: <type>).Admins can only read/write data belonging to their own
bookkeeperOrgId;
employees only their own company. Accessing another tenant’s resource returns
403.GET /api/v1/admin/industries works with or without a token.
Example: authenticate and call an endpoint
data.token of the login response.
Admin login
Full reference for
POST /api/v1/auth/login.