Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Nieto2020/portalhub/llms.txt

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

The PortalHub backend exposes a set of PHP endpoints that power the full-stack accounting consultancy portal. Every endpoint is a discrete PHP file that accepts JSON request bodies, enforces session-based authentication, and returns a uniform JSON response envelope. The API is organized into functional modules — auth, users, appointments, documents, payments, messages, notifications, reports, and assignments — each living under its own subdirectory inside backend/modules/.

​
Base URL

All requests target the development server at: 
http://localhost:8000/backend/modules/
Routing is file-based rather than through a front controller. Each endpoint is addressed by its full path relative to this base, for example: 
POST http://localhost:8000/backend/modules/auth/login.php
GET  http://localhost:8000/backend/modules/auth/check_session.php
In a production deployment the base URL changes to match your domain, but the module paths remain identical. Always use HTTPS in production — the session cookie is automatically marked Secure when the server detects a TLS connection.

​
Response Envelope

Every endpoint — success or error — returns Content-Type: application/json and a consistent three-field envelope: 
{
  "status": 200,
  "message": "Success message",
  "data": { ... }
}
FieldTypeDescription
statusintegerMirrors the HTTP response status code.
messagestringHuman-readable outcome description.
dataobject | nullPayload for successful responses; null when not applicable.

​
HTTP Status Codes

CodeMeaningWhen it occurs
200 OKRequest succeededStandard success for GET and mutating POST requests.
201 CreatedResource createdReturned when a new record is successfully inserted (e.g. user registration).
400 Bad RequestValidation failureMissing required fields, invalid email format, mismatched passwords, or duplicate unique values.
401 UnauthorizedAuthentication requiredNo active session, invalid credentials, or session expired after 1 800 seconds of inactivity.
403 ForbiddenAuthorization failureInsufficient role permissions, inactive user account, or a mandatory password change is pending.
405 Method Not AllowedWrong HTTP verbAn endpoint received a verb it does not handle (e.g. GET on a POST-only route).
500 Internal Server ErrorServer-side faultUnhandled PDO or database exception. Details are written to the server error log, not exposed to the client.

​
Content-Type

All endpoints expect Content-Type: application/json for request bodies and always respond with Content-Type: application/json. Pass a JSON-encoded body for every POST request: 
curl -X POST http://localhost:8000/backend/modules/auth/login.php \
  -H "Content-Type: application/json" \
  -d '{"correo":"user@example.com","password":"secret"}'

​
Authentication Model

PortalHub uses server-side PHP sessions ($_SESSION). After a successful login the server creates a session and sends a PHPSESSID cookie to the browser. Every subsequent request to a protected endpoint must include that cookie. Three roles are defined in config/config.php:
ConstantValueDescription
ROL_ADMIN1Full platform access; can register new users.
ROL_ASESOR2Advisor-level access to assigned clients.
ROL_CLIENTE3Client-level access to own data only.
The checkAuth() middleware validates the session on every protected endpoint. checkRole(array $allowedRoles) extends that check to enforce role membership.

​
Session Timeout

Sessions expire after 1 800 seconds (30 minutes) of inactivity. The ultima_actividad timestamp in $_SESSION is refreshed on each authenticated request. If the gap between the current time and ultima_actividad exceeds the timeout, the session is destroyed and a 401 is returned.
After a session expires the client must log in again to obtain a fresh PHPSESSID and CSRF token. Clients that store the cookie manually (e.g. in automated scripts) should handle 401 responses by re-authenticating.

​
CSRF Protection

After a successful login a 64-character hex CSRF token is generated with bin2hex(random_bytes(32)) and stored in $_SESSION['csrf_token']. Endpoints that mutate state require this token to be supplied either:
  • In the request body as "csrf_token": "<token>", or
  • In the X-CSRF-Token request header.
The token is regenerated after every successful password change. Fetch the current token at any time from the GET /auth/csrf_token.php endpoint.
Single-page application frontends should store the CSRF token in memory (not in localStorage) and attach it to every mutating request automatically via an Axios interceptor or equivalent.

​
API Modules

Authentication

Login, logout, session checks, CSRF token retrieval, password updates, and admin user registration.

Users

Manage user profiles, roles, status, and account details for admins, advisors, and clients.

Appointments

Schedule, update, and cancel consultancy appointments between advisors and clients.

Documents

Upload, retrieve, and manage accounting documents attached to client files.

Payments

Record and query payment transactions associated with consultancy services.

Messages

Internal messaging between users across all roles within the portal.

Notifications

System-generated and manual notifications delivered to user dashboards.

Reports

Generate and retrieve accounting and activity reports for advisors and administrators.

Assignments

Manage advisor-to-client assignments that control access and visibility within the portal.

Build docs developers (and LLMs) love

Get started for freeTalk to us