This project uses OpenAPI 3.0 (formerly Swagger) for API documentation.
Once the server is running, you can access the interactive API documentation at:
http://localhost:8080/api-docs
All API endpoints are documented using OpenAPI 3.0 specification with JSDoc comments in the controller files.
Example:
/**
* @openapi
* /api/users:
* post:
* summary: Create a new user
* description: Create a user via Temporal workflow
* tags:
* - Users
* requestBody:
* required: true
* content:
* application/json:
* schema:
* type: object
* required:
* - email
* - name
* - mobile
* properties:
* email:
* type: string
* format: email
* name:
* type: string
* mobile:
* type: string
* responses:
* 201:
* description: User created successfully
* 400:
* description: Bad request
* 409:
* description: Duplicate found
*/
async function create(req, res, next) {
// implementation
}The Swagger configuration is located at src/config/swagger.js.
- OpenAPI Version: 3.0.0
- Authentication: Bearer JWT tokens
- Reusable Schemas: Defined in
components.schemas - Auto-discovery: Automatically scans
src/api/**/*.controller.jsfiles
- POST /api/users - Create a new user
- GET /api/users - Get all users (paginated)
- GET /api/users/:id - Get a single user by ID
- PUT /api/users/:id - Update a user
All user endpoints use Temporal workflows for processing.
The following reusable schemas are defined:
User- Complete user objectUserInput- Input for user creationUserUpdate- Input for user updatesError- Standard error responseSuccessResponse- Standard success response
When creating new endpoints:
- Add OpenAPI JSDoc comments above the controller function
- Follow the existing format
- Use reusable schemas where possible
- Include all possible response codes
- Add examples for clarity
You can test the API directly from the Swagger UI at /api-docs or use the "Try it out" feature for each endpoint.
- Always document all parameters - path, query, body
- Include response examples - helps developers understand the API
- Use proper HTTP status codes - 200, 201, 400, 404, 409, 500, etc.
- Tag endpoints logically - group related endpoints with tags
- Keep descriptions clear - explain what the endpoint does
- Document error cases - include all possible error responses