Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/ytabeloved/ordervista/llms.txt

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

The Ordervista REST API is a Node.js/Express backend that powers a full-stack restaurant order management system. It provides structured endpoints for every operational domain — from authentication and user management through live order handling, kitchen commands, and sales reporting — all secured with JWT Bearer tokens and enforced per-role access control.

Base URL

EnvironmentBase URL
Local developmenthttp://localhost:3000/api
Productionhttps://ordervista-backend.onrender.com/api
All endpoints described in this reference are relative to the base URL above. For example, POST /api/auth/login in production becomes https://ordervista-backend.onrender.com/api/auth/login.

Available Route Groups

Auth

Register, log in, and log out. The /api/auth group issues the JWT tokens required by all protected routes.

Users

Create, retrieve, update, and delete system users. Restricted to the Admin role for management operations.

Categories

Manage product categories, including activation and deactivation, to keep the menu organised.

Products

Full CRUD for menu products: name, description, category, price, stock, image, and availability status.

Menu

Read-only public menu view consumed by the customer-facing storefront to list available products.

Orders

Create online and in-person orders, update order status, and retrieve order detail with line items and totals.

Commands

Kitchen command (comanda) management. Operators retrieve and action commands to coordinate food preparation.

Addresses

Store and manage customer delivery addresses used when placing online orders.

Reports

Administrative sales reports: estimated revenue, order counts, average ticket, top-selling products, and date-range filters.
In addition to the groups above, the API registers /api/order-types (available in both the app and server modules) for retrieving the configured order-type options (e.g. online, in-person) used when creating orders.

Health Check

Before making authenticated requests, you can verify the API is reachable with the public health endpoint. No authentication header is required.
GET /api/health
Response 200 OK
{
  "status": "ok",
  "message": "OrderVista API running"
}
Call /api/health first whenever you test against the production environment. Because the backend is hosted on Render’s free tier, the server may take a few seconds to wake from idle before returning a response.

Authentication

All route groups except /api/auth and the public menu are protected. Every request to a protected endpoint must carry a valid JWT in the Authorization header:
Authorization: Bearer <token>
Tokens are obtained by calling POST /api/auth/login with valid credentials. See the Authentication page for the full login flow, token payload details, and error reference.

Role Enforcement

Ordervista defines three user roles. Each role value is an integer stored in the id_rol field of both the database record and the JWT payload:
Role IDNameDescription
1AdminFull system access: users, categories, products, dashboard, and reports
2OperatorOperational access: view and create orders, manage order states, handle commands and receipts
3CustomerSelf-service access: browse the menu, place online orders, and view own order history
After verifyToken validates the JWT, the authorizeRoles middleware checks req.user.id_rol against the roles permitted for that specific route. Requests from a role that is not on the allowed list receive a 403 Forbidden response.

Response Format

All responses — success and error — are returned as application/json. Successful retrieval — 200 OK
{
  "data": { }
}
Successful creation — 201 Created Responses for create operations include the newly generated resource identifier:
{
  "mensaje": "Recurso creado correctamente",
  "id": 42
}
Error responses Errors are returned with a human-readable mensaje field:
{
  "mensaje": "Token inválido o expirado"
}
Common HTTP status codes used across the API:
StatusMeaning
200Request succeeded
201Resource created successfully
400Bad request — validation or missing field
401Unauthorised — missing, invalid, or expired token
403Forbidden — authenticated but insufficient role
404Resource not found
500Internal server error

Content-Type

All request bodies must be sent as JSON. Include the following header on every POST, PUT, or PATCH request:
Content-Type: application/json
Requests that omit this header or send a non-JSON body will not be parsed correctly and may return unexpected errors.

Build docs developers (and LLMs) love