Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/ttpullima/RomsoftBackEnd2021_v2/llms.txt

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

The Login endpoint is the entry point into every authenticated workflow in the Romsoft Gestión Clínica API. It accepts a username and password, validates them against the system’s user store, and — on success — returns a session object containing the user’s identity, role assignment, and a security token that must be forwarded with every subsequent request. Because authentication must be reachable before any token exists, this route is decorated with [AllowAnonymous] and requires no Authorization header.

​
Endpoint

POST /api/Account/Login
This is the only endpoint in the API that does not require an Authorization header. Every other controller action expects Authorization: Bearer <token> once a session has been established.

​
Request Body

Send a JSON object that matches the LoginDTO shape. Both fields are required for a successful credential look-up.
​
Username
string
required
The system username assigned to the user account. Case-sensitivity depends on the underlying database collation.
​
Password
string
required
The account password. Transmitted in the request body — always use HTTPS in production to protect credentials in transit.
​
ValidacionAD
boolean
Optional flag indicating whether to validate the user against Active Directory instead of the local credential store. Defaults to false when omitted.

​
Example Request

curl -X POST https://<your-server>/api/Account/Login \
  -H "Content-Type: application/json" \
  -d '{"Username": "admin", "Password": "your-password"}'

​
Response Envelope

All API responses are wrapped in a JsonResponse envelope before the Data payload is returned. The envelope fields are consistent across every endpoint.
​
Success
boolean
true when the request was processed without a server-side exception. A true value does not necessarily mean credentials were valid — inspect Warning and Message for authentication outcomes.
​
Warning
boolean
Set to true when the request completed successfully from an infrastructure perspective but the business rule was not satisfied — for example, when the supplied credentials do not match any user in the system.
​
Message
string
A human-readable status message in Spanish. Populated on warnings and errors.
​
Data
object
On a successful login, contains a SEG_USUARIOLoginDTO object with the authenticated user’s session data. null when authentication fails.

​
Response Scenarios

​
✅ Successful Authentication

When credentials are found in the system, Success is true, Warning is absent (or false), and Data contains the SEG_USUARIOLoginDTO object. 
{
  "Success": true,
  "Warning": false,
  "Message": null,
  "Data": {
    "id_usuario": 1,
    "id_rol": 2,
    "usuario": "admin",
    "clave": "**********",
    "apellidos": "Quispe Mamani",
    "nombres": "Carlos Alberto",
    "estado": "A",
    "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
  }
}

​
⚠️ Invalid Credentials

When no matching user is found for the supplied username and password combination, the API responds with Success: true (no server error occurred) but sets Warning: true and populates Message with the Spanish-language rejection message. 
{
  "Success": true,
  "Warning": true,
  "Message": "El usuario no pertenece al sistema.",
  "Data": null
}

​
❌ Server Error

If an unhandled exception occurs while processing the request, Success is set to false and a generic retry message is returned. The error is logged internally by the BaseController. 
{
  "Success": false,
  "Warning": false,
  "Message": "Hubo un error, inténtelo más tarde.",
  "Data": null
}

​
Using the Token in Subsequent Requests

Once you have retrieved the token value from the Data object, attach it to the Authorization header of every protected request: 
curl -X POST https://<your-server>/api/SEG_USUARIO/GetAllFilters \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." \
  -d '{}'
Store the token in a secure, session-scoped variable in your client application. Do not persist it to localStorage or any unencrypted storage medium, as it grants full API access under the authenticated user’s role.

Build docs developers (and LLMs) love

Get started for freeTalk to us