General POS System — Multi-tenant REST API (Node.js / Express), self-hosted via Docker
This project is a backend API, not a consumer application. It stores whatever the businesses using it send through their own point-of-sale clients. Each tenant is the controller of its own data; the API acts as the processor.
General POS System is deployed by each business on its own servers. That business decides what is stored and is the data controller; the API is the processor acting on its instructions. The developer operates no shared instance and receives no telemetry from any deployment.
This page describes the categories of data the API handles by design, so an operator can write their own customer-facing policy on top of it.
| Data | Why |
|---|---|
| Tenant and user accounts | Business name, user name, email, role, and a hashed password (bcrypt/argon2). Used for authentication and role-based access control. |
| Product catalogue | Products, variants, SKUs, prices, and stock levels — business data, not personal data. |
| Transactions | Line items, totals, payment methods, cashier, and timestamps. Customer identity is optional and only present if the tenant’s client sends it. |
| Authentication tokens | Short-lived JWT access tokens and refresh tokens; refresh tokens can be revoked server-side. |
| Cache entries (Redis) | Session state and frequently read data, held temporarily with a short expiry. |
| Request logs | IP address, endpoint, HTTP status, tenant ID, and timestamp — for debugging, rate limiting, and abuse detection. |
Every request is scoped to the tenant encoded in the authenticated token. One tenant cannot read or write another tenant’s records through the API. Administrative endpoints are gated by role, and role assignment is the operator’s responsibility.
Tenants can register webhook URLs to receive transaction events. When they do, the payload — which may include customer or order details — is delivered to that external endpoint. Choosing a destination, securing it, and disclosing that transfer to its own customers is the tenant’s responsibility, not the API’s.
The API itself calls no external service. Payment providers, messaging services, and any other integration are configured by the tenant, run under the tenant’s own credentials, and are governed by those providers’ policies.
Nothing is deleted automatically except cache entries (which expire) and rotated request logs. Business and transaction records persist until the operator deletes them or applies its own retention policy through the API.
The application applies standard protections: passwords are stored as one-way hashes (never in plain text), access is limited by role, and all traffic between client and server is expected to run over HTTPS/TLS.
Passwords are hashed, tokens expire and can be revoked, endpoints validate input, and the container image ships with no default credentials. TLS termination, database encryption at rest, backups, and network policy are configured by the operator on their own infrastructure.
No system is perfectly secure. Server hardening, backups, and access management for a live installation are the responsibility of the organization operating it.
The API is business software with no consumer-facing sign-up. It is not intended for use by children.
If you are a customer of a business that runs this API, that business holds your data — send access or deletion requests to them. If you are an operator and need help implementing such a request technically, contact mhdlutfidev@gmail.com.
If this policy changes, the “Last updated” date at the top of this page will be revised. Material changes will be reflected in the application release notes.
Questions, complaints, or privacy requests about this application:
I aim to respond within 7 business days.