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 Romsoft Gestión Clínica API uses a straightforward request/response model: you obtain a JWT bearer token by logging in, then attach that token to every subsequent call. All endpoints accept JSON bodies and return the same JsonResponse envelope. This guide walks you through the complete flow from first login to querying real clinical data in five steps.

Prerequisites

Before you begin, make sure you have:
  • Base URL — The API is hosted at your server’s deployment address. All endpoint paths follow the pattern https://<your-server>/api/{Controller}/{Action}. Replace <your-server> with your actual hostname (e.g., https://romsoft.yourclinic.com).
  • A valid user account — You need a username and password already created in the system by an administrator. The SEG_USUARIO table must contain an active record for your credentials.
  • An HTTP client — The examples below use curl. Any HTTP client (Postman, Insomnia, your preferred language SDK) works equally well.
Every endpoint in this API uses the POST HTTP method, including read/query operations. There are no GET, PUT, PATCH, or DELETE routes — all interactions are via POST.

1

Log in and obtain your token

Call POST /api/Account/Login with your username and password. This is the only endpoint that does not require an Authorization header — it is decorated with [AllowAnonymous] in the server code.
curl -X POST https://<your-server>/api/Account/Login \
  -H "Content-Type: application/json" \
  -d '{
    "Username": "admin",
    "Password": "yourpassword"
  }'
A successful response looks like this:
{
  "Success": true,
  "Warning": false,
  "Message": null,
  "Data": {
    "id_usuario": 1,
    "id_rol": 2,
    "usuario": "admin",
    "clave": "***",
    "apellidos": "Pullima",
    "nombres": "Administrador",
    "estado": "A",
    "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
  }
}
If the credentials are wrong, the server returns Success: true, Warning: true with a message indicating the user does not exist — it does not return a 4xx HTTP status code for bad credentials.
{
  "Success": true,
  "Warning": true,
  "Message": "El usuario no existe o los datos son incorrectos.",
  "Data": null
}
2

Extract the token and attach it to requests

Copy the token string from Data.token in the login response. You must send this value as a Bearer token in the Authorization header of every subsequent request.
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
The token is a signed JWT. The server validates it on every request using the TokenValidationHandler delegating handler registered in the pipeline. Tokens expire after 20 days by default (JWT_EXPIRE_MINUTES = 28800, which is 28,800 minutes). After expiry you must log in again to obtain a fresh token.Store the token securely — treat it like a session credential. Do not log it or embed it in client-side source code.
3

Fetch active insurance plans

With a valid token in hand, try fetching all active insurance plans. Send an empty JSON body — the endpoint requires a POST but takes no filter parameters.
curl -X POST https://<your-server>/api/CVN_PLAN_SEGURO/GetAllActives \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." \
  -d '{}'
A successful response returns the list of active plans inside Data:
{
  "Success": true,
  "Warning": false,
  "Message": null,
  "Data": [
    {
      "id_plan_seguro": 1,
      "descripcion": "SIS GRATUITO",
      "estado": "A"
    },
    {
      "id_plan_seguro": 2,
      "descripcion": "ESSALUD",
      "estado": "A"
    }
  ]
}
If you omit the Authorization header entirely, the request passes through TokenValidationHandler without a token and the endpoint’s own authorization check will reject it with 401 Unauthorized.
4

Query patients with filters

Patient records support filtered searches via POST /api/ADM_PACIENTE/GetAllFilters. Pass a JSON body containing the filter criteria. All fields are optional — an empty object returns all patients subject to server-side pagination limits.
curl -X POST https://<your-server>/api/ADM_PACIENTE/GetAllFilters \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." \
  -d '{
    "apellidos": "Garcia",
    "estado": "A"
  }'
The response returns a list of matching patient records in Data:
{
  "Success": true,
  "Warning": false,
  "Message": null,
  "Data": [
    {
      "id_paciente": 42,
      "apellidos": "Garcia Lopez",
      "nombres": "Maria Elena",
      "dni": "45678901",
      "estado": "A"
    }
  ]
}
If no patients match the filter criteria, Data will be an empty array ([]) and Warning will remain false — an empty result set is a valid, successful response.
5

Explore the full API reference

You now know the fundamental pattern for every interaction with the API:
  1. POST to an endpoint with a JSON body.
  2. Read the JsonResponse envelope (Success, Warning, Message, Data).
  3. Include Authorization: Bearer <token> on all calls except /api/Account/Login.
The complete endpoint reference — with full request/response schemas for every controller and action — is available in the API reference section.

Login Endpoint Reference

Full schema documentation for POST /api/Account/Login, including all request fields and response field descriptions.

Build docs developers (and LLMs) love