Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/CLINTONARMANDO/apiregistropendientes/llms.txt

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

Every pendiente moves through a defined lifecycle. The API enforces a strict state machine — only certain transitions are allowed, and attempting an invalid transition returns an error. Understanding the state model helps you build correct workflows, debug unexpected failures, and design dashboards that accurately reflect field operations.

The 10 main states

StateMeaning in field operations
REGISTRADOThe work order has been created and is waiting for a technician to be assigned.
ASIGNADOA technician has been assigned. The work is scheduled but not yet started.
EN_PROGRESOThe technician is actively on-site performing the work.
PAUSADOWork has been interrupted (e.g., missing materials, client not at home) and will resume later.
REVISIONThe work is under internal review before proceeding to validation.
POR_VALIDARThe technician has reported the work as finished. A supervisor must validate it.
OBSERVADOThe supervisor has found an issue during validation and has returned it for the technician to address.
FINALIZADOThe work order is complete and accepted. No further changes are permitted.
POSTERGADOThe work has been postponed to a future date without being cancelled.
CANCELADOThe work order has been cancelled. It can be recovered to POSTERGADO if needed.
REVISION is an intermediate state available in the system but not listed in the standard dispatch flow. It is used by some teams before escalating to POR_VALIDAR.

State transition rules

The API enforces the following transitions. Requesting a transition not listed here will return a 400 Bad Request.

From REGISTRADO

Target stateAction
ASIGNADOAssign a technician to the work order.
CANCELADOCancel the work order before any work begins.
POSTERGADOPostpone the work order to a later date.

From ASIGNADO

Target stateAction
EN_PROGRESOTechnician arrives on-site and starts work.
REGISTRADOReassign to a different technician (removes current assignment).
CANCELADOCancel after assignment but before work starts.

From EN_PROGRESO

Target stateAction
PAUSADOPause work (waiting for parts, access issues, etc.).
POR_VALIDARTechnician marks the job as finished, ready for supervisor review.
CANCELADOCancel while work is in progress.
REGISTRADOReassign — removes technician and returns to the dispatch queue.

From PAUSADO

Target stateAction
EN_PROGRESOResume work after the pause is resolved.
POR_VALIDARMark as finished directly from a paused state.
CANCELADOCancel a paused work order.
REGISTRADOReassign from paused state.

From POR_VALIDAR

Target stateAction
FINALIZADOSupervisor accepts the work. The pendiente is closed.
OBSERVADOSupervisor finds an issue and returns it to the technician.

From OBSERVADO

Target stateAction
POR_VALIDARTechnician addresses the observation and resubmits for validation.

From POSTERGADO

Target stateAction
ASIGNADOAssign a technician now that the postponement is resolved.
POSTERGADOPostpone again to a new future date.

From CANCELADO

Target stateAction
POSTERGADORecover a cancelled order by converting it to a postponed one.
FINALIZADO is a terminal state. There are no transitions out of FINALIZADO. If a finalised work order needs to be reopened, a new pendiente must be created.

A complete transition reference

The table below gives a single consolidated view of every valid transition in the system:
FromToTrigger
REGISTRADOASIGNADOAssign technician
REGISTRADOCANCELADOCancel
REGISTRADOPOSTERGADOPostpone
ASIGNADOEN_PROGRESOStart work
ASIGNADOREGISTRADOReassign
ASIGNADOCANCELADOCancel
EN_PROGRESOPAUSADOPause
EN_PROGRESOPOR_VALIDARFinish work
EN_PROGRESOCANCELADOCancel
EN_PROGRESOREGISTRADOReassign
PAUSADOEN_PROGRESOResume
PAUSADOPOR_VALIDARFinish
PAUSADOCANCELADOCancel
PAUSADOREGISTRADOReassign
POR_VALIDARFINALIZADOSupervisor approves
POR_VALIDAROBSERVADOSupervisor observes issue
OBSERVADOPOR_VALIDARTechnician resubmits
POSTERGADOASIGNADOAssign technician
POSTERGADOPOSTERGADOPostpone again
CANCELADOPOSTERGADORecover as postponed

The EstadoTecnico sub-state system

Some pendiente types require network configuration work (PPPoE credentials, VLAN assignment) that is performed by a separate network team, not the field technician. The estadoTecnico field tracks this sub-process independently of the main estado.

The four sub-states

ValueMeaning
OKNo pending network tasks. The pendiente can proceed to FINALIZADO.
PENDIENTE_PPPoEA PPPoE configuration has been requested. The network team must provision the credentials.
PENDIENTE_VLANA VLAN assignment has been requested. The network team must configure the access switch port.
PENDIENTE_PPPoE_Y_VLANBoth PPPoE and VLAN configurations are pending. Both must be completed before the order can finalise.

EstadoTecnico transitions

FromToTrigger
OKPENDIENTE_PPPoETechnician or dispatcher requests PPPoE provisioning
OKPENDIENTE_VLANTechnician or dispatcher requests VLAN assignment
PENDIENTE_PPPoEPENDIENTE_PPPoE_Y_VLANVLAN also requested while PPPoE is pending
PENDIENTE_VLANPENDIENTE_PPPoE_Y_VLANPPPoE also requested while VLAN is pending
PENDIENTE_PPPoEOKNetwork team completes PPPoE configuration
PENDIENTE_VLANOKNetwork team completes VLAN configuration
PENDIENTE_PPPoE_Y_VLANOKNetwork team completes both configurations
The estadoTecnico is independent of estado. A pendiente can be in EN_PROGRESO with estadoTecnico = PENDIENTE_PPPoE. The field technician can mark work as done (POR_VALIDAR) while the network task is still outstanding — but supervisors should check estadoTecnico before approving FINALIZADO.

Changing state via the API

State transitions are performed with a single PUT request:
PUT /api/pendientes/{id}/estado
The request body specifies the target state and, for assignment transitions, the technician to assign:
{
  "estado": "ASIGNADO",
  "empleadoId": 42
}
The API validates both the transition legality and the caller’s permissions before applying the change. If either check fails, the response is 400 Bad Request or 403 Forbidden respectively.

Example: complete internet installation flow

The following walkthrough shows a typical internet installation from creation to completion.
1

Create the pendiente

A dispatcher creates a new pendiente with tipo = INSTALACION_INTERNET, sets fechaPendiente, links it to the client, and sets prioridad = MEDIA. The initial estado is REGISTRADO and estadoTecnico is OK.
2

Assign a technician

The dispatcher calls PUT /api/pendientes/{id}/estado with estado = ASIGNADO and the technician’s empleadoId. The state moves from REGISTRADOASIGNADO.
Requires the ASIGNAR_TECNICO permission.
3

Technician starts work on-site

The technician arrives at the client’s address and calls the API with estado = EN_PROGRESO. State moves from ASIGNADOEN_PROGRESO.
4

Request PPPoE provisioning

After cabling is complete, the technician raises a PPPoE request: PUT /api/pendientes/{id}/estadoTecnico with estadoTecnico = PENDIENTE_PPPoE. The estadoTecnico moves from OKPENDIENTE_PPPoE.
5

Network team provisions PPPoE

A network engineer assigns credentials and marks the task done: PUT /api/pendientes/{id}/estadoTecnico with estadoTecnico = OK. The estadoTecnico returns to OK.
6

Technician marks work as finished

With cabling done and PPPoE configured, the technician submits: estado = POR_VALIDAR. State moves from EN_PROGRESOPOR_VALIDAR.
7

Supervisor finalises the work order

A supervisor reviews the job, confirms estadoTecnico = OK, and calls the API with estado = FINALIZADO. The pendiente is now closed.
If the supervisor discovers an issue during review, they can move the pendiente to OBSERVADO instead of FINALIZADO. The technician addresses the issue and resubmits to POR_VALIDAR for a second review.

Build docs developers (and LLMs) love