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.

Every endpoint in the Gestión Clínica API — whether it creates a patient record, retrieves a list of insurance plans, or authenticates a user — returns the same JSON envelope. This uniformity means client code never needs to check HTTP status codes or parse exception bodies: all outcome signals live inside a predictable top-level object called JsonResponse, defined in Romsoft.GESTIONCLINICA.Common.

​
Envelope Fields

​
Success
boolean
required
Indicates whether the operation completed without a server-level error. A value of true does not necessarily mean the business action succeeded — check Warning for that distinction. A value of false means an unhandled exception occurred; the client should show the Message and retry later.
​
Warning
boolean
required
Raised to true when the request was processed without error but a business rule prevented the desired change — for example, a duplicate patient record was detected or a related record would be orphaned. When Warning is true, Success is still true and Message contains the reason in Spanish.
​
Message
string
A human-readable explanation in Spanish. Present on warnings (Warning=true) and errors (Success=false). Typically absent (null or empty string) on clean success responses. All standard messages are defined as static strings in Romsoft.GESTIONCLINICA.WebApi.Core.Mensajes.
​
Data
object
The payload of the response. Can be a single object, an array, a primitive value, or null. The shape depends entirely on the endpoint — refer to each controller’s action documentation for the concrete type.
The Warning flag is the key to the three-outcome model. A false/false combination (no success, no warning) only occurs during unhandled exceptions. Any situation the business logic explicitly anticipates — duplicates, missing references, validation failures — is expressed as Success=true, Warning=true so the client knows the server is healthy and can display the reason message without treating it as an infrastructure failure.

​
Response Scenarios

​
1. Clean Success

The operation completed and the payload is in Data. Message is typically the localised confirmation string (e.g., "Se registró satisfactoriamente."). 
{
  "Success": true,
  "Warning": false,
  "Message": "Se registró satisfactoriamente.",
  "Data": null
}
For a read/query endpoint the Data field carries the result set: 
{
  "Success": true,
  "Warning": false,
  "Message": null,
  "Data": [
    {
      "IdPaciente": 1042,
      "ApellidoPaterno": "Quispe",
      "ApellidoMaterno": "Ramos",
      "Nombres": "Carlos Alberto",
      "NumeroDocumento": "41234567"
    }
  ]
}

​
2. Business Rule Warning

The request was valid and the server is healthy, but the action was blocked by a domain rule. Success remains true so the client knows this is an expected outcome, not an infrastructure failure. 
{
  "Success": true,
  "Warning": true,
  "Message": "El registro ya existe.",
  "Data": null
}
Other common warning messages from Mensajes.cs:
ScenarioMessage
Duplicate record"El registro ya existe."
Dependent data prevents deletion"Hay datos que dependen de él, elimínelos para que pueda eliminar este registro."
Only one active allowed"Solo puede haber un activo."
Registration failed (DB-level)"No se pudo realizar el registro."

​
3. Server / Exception Error

An unhandled exception was caught in the controller’s catch block. Success is false. LogError(ex) has already written the full stack trace to the log4net rolling file. The client receives a generic message and should not retry automatically. 
{
  "Success": false,
  "Warning": false,
  "Message": "Hubo un error, inténtelo más tarde.",
  "Data": null
}

​
C# Source Definition

The JsonResponse class in Romsoft.GESTIONCLINICA.Common/JsonResponse.cs is minimal by design: 
public class JsonResponse
{
    public string Message { get; set; }
    public bool Success { get; set; }
    public bool Warning { get; set; }
    public object Data { get; set; }
}
Controllers construct the envelope inline and return it directly from the action method: 
[HttpPost]
public JsonResponse Add(ADM_PACIENTEDTO pacienteDTO)
{
    var jsonResponse = new JsonResponse { Success = true };
    try
    {
        var paciente = MapperHelper.Map<ADM_PACIENTEDTO, ADM_PACIENTE>(pacienteDTO);

        if (!ADM_PACIENTEBL.Instancia.Exists(paciente))
        {
            var resultado = ADM_PACIENTEBL.Instancia.Add2(paciente);
            if (resultado.Item1 > 0)
                jsonResponse.Message = Mensajes.RegistroSatisfactorio;
            else
            {
                jsonResponse.Warning = true;
                jsonResponse.Message = resultado.Item2;
            }
        }
        else
        {
            jsonResponse.Warning = true;
            jsonResponse.Message = Mensajes.YaExisteRegistro;
        }
    }
    catch (Exception ex)
    {
        LogError(ex);
        jsonResponse.Success = false;
        jsonResponse.Message = Mensajes.IntenteloMasTarde;
    }
    return jsonResponse;
}

​
Paginated Endpoints

Endpoints that return potentially large result sets accept a PaginationParameter object in the POST body. The BL layer passes this to GetAllPaging on the repository, which translates the parameters into SQL OFFSET/FETCH or equivalent logic in the stored procedure. 
public class PaginationParameter
{
    public string OrderBy { get; set; }    // Column name for ORDER BY
    public int Start { get; set; }         // Zero-based row offset
    public int CurrentPage { get; set; }   // 1-based current page number
    public int AmountRows { get; set; }    // Page size (rows per page)
    public string WhereFilter { get; set; } // Optional dynamic filter string
}
A paginated request looks like: 
{
  "OrderBy": "ApellidoPaterno",
  "Start": 0,
  "CurrentPage": 1,
  "AmountRows": 20,
  "WhereFilter": ""
}
The response wraps the page of records in the standard Data field: 
{
  "Success": true,
  "Warning": false,
  "Message": null,
  "Data": [
    { "IdPaciente": 1, "Nombres": "María" },
    { "IdPaciente": 2, "Nombres": "Luis" }
  ]
}
Because Data is typed as object, deserialize it on the client side using the known DTO type for each specific endpoint. For example, a call to POST /api/ADM_PACIENTE/GetAllPaging should deserialize Data as List<ADM_PACIENTEDTO>.

Build docs developers (and LLMs) love

Get started for freeTalk to us