Authentication

This endpoint allows users to authenticate using their grant_type, username, and password. Upon successful authentication, an access token is returned, which must be included in the Authorization header for all subsequent protected API requests.
Endpoint: POST http://atlas.aptsys.com.sg/api/v1/auth/login
Method: POST
Content-Type: application/json
Authentication: None (this endpoint issues credentials)

Request Body

Field	Type	Required	Description
grant_type	string	Yes	Must be password
username	string	Yes	User’s login name
password	string	Yes	User’s password

Example Request

{
  "grant_type": "password",
  "username": "manager_li",
  "password": "mySecurePass123!"
}

Successful Response (HTTP 200)

Response Fields

Field	Type	Description
access_token	string	JWT access token (valid for 2 hours)
token_type	string	Always "Bearer"
expires_in	number	Token lifetime in seconds (e.g., 7200)

Example Response

{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.xxxxx",
  "token_type": "Bearer",
  "expires_in": 7200
}

Error Responses

HTTP Status	Reason	Example Response Body
400	Missing or invalid request fields	{"error": "Missing required field: password"}
401	Invalid username, or password	{"error": "Invalid credentials"}
403	User account is disabled	{"error": "Account disabled"}
429	Too many failed login attempts (rate-limited)	{"error": "Too many attempts. Try again later."}
500	Internal server error	{"error": "Internal server error"}

Example Error (401)

{
  "error": "Invalid credentials"
}

Using the Access Token

Include the token in the Authorization header for protected endpoints:

Authorization: Bearer <access_token>

Example:

POST http://atlas.aptsys.com.sg/api/v1/sales/upload-hourly
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.xxxxx

Additional Notes

• Each login generates a new token; previous tokens remain valid until expiration unless explicitly revoked.
• Tokens expire after 2 hours (7200 seconds). A refresh token mechanism can be added later if needed.
• Restaurant IDs are assigned by the system administrator and are not user-generated.
• Failed login attempts may trigger rate-limiting or temporary lockout (implementation-dependent).