Authentication API

Login, logout, refresh, CSRF, current user and health endpoints.

Authentication supports browser sessions and PAT-based integration. Browser sessions use the ces_session cookie and CSRF protection. Server integrations normally use Authorization: Bearer <PAT>.

Endpoints

MethodPathDescription
GET/healthPublic service health check
GET/api/v1/health/liveLiveness probe
GET/api/v1/health/readyReadiness probe
POST/api/v1/auth/loginAuthenticate with email and password; sets session cookie
POST/api/v1/auth/logoutClear current session
POST/api/v1/auth/refreshRefresh current session
GET/api/v1/auth/csrfReturn CSRF token for cookie-authenticated writes
POST/api/v1/auth/forgot-passwordStart password reset flow
GET/api/v1/auth/meReturn current authenticated user and tenant context

POST /api/v1/auth/login

Request body (LoginDto)

FieldTypeRequiredDescription
emailstring (email)yesUser email address
passwordstringyesPassword, 8 to 128 characters
Shell
curl -X POST {{BASE_URL}}/api/v1/auth/login \
-H "Content-Type: application/json" \
-d '{ "email": "user@example.com", "password": "********" }'

200 OK authenticates the user and sets the ces_session cookie.

Session endpoints

MethodPathSuccess
POST/api/v1/auth/logout204 No Content
POST/api/v1/auth/refresh200 OK
GET/api/v1/auth/csrf200 OK
GET/api/v1/auth/me200 OK

Use the CSRF token as X-CSRF-Token on cookie-authenticated POST, PUT, PATCH and DELETE requests.

POST /api/v1/auth/forgot-password

Request body (ForgotPasswordDto)

FieldTypeRequiredDescription
emailstring (email)yesAccount email address

204 No Content means the request was accepted. The response does not reveal whether the email exists.

Health endpoints

GET /health and GET /api/v1/health/live return 200 OK when the process is alive. GET /api/v1/health/ready returns 200 OK when dependencies are ready and 503 Service Unavailable when they are not.