Skip to main content
Every ticket in Mesa de Ayuda follows a defined state machine. Understanding the available states and how to move between them helps you integrate correctly with the API and build reliable automations.

Ticket identifiers

Each ticket has two identifiers assigned at creation:
FieldFormatExamplePurpose
ticket_uuidUUID v43f7a1b2c-...Stable internal ID used in API paths (/tickets/{ticket_id})
ticket_labelHuman-readable labelTK-2024-00042Displayed to requesters for follow-up via /consultar
Both identifiers are returned by fn_crear_ticket and included in the response from POST /tickets/crear.

Ticket types

When creating a ticket you must specify its tipo. The valid values are:
PETICION · QUEJA · RECLAMO · SUGERENCIA · INCIDENTE · SOLICITUD · CONSULTA

State machine

The diagram below shows all states and the operations that cause transitions between them.
                        ┌─────────────┐
                        │    NUEVO    │  ← created via /crear
                        └──────┬──────┘
                               │ asignar

                        ┌─────────────┐
                        │  ASIGNADO   │
                        └──────┬──────┘

              ┌────────────────┼────────────────┐
              │                │                │
           pausar          transferir       reclasificar
              │                │                │
              ▼                ▼                ▼
       ┌──────────┐    ┌──────────────┐  ┌──────────────┐
       │ PAUSADO  │    │ TRANSFERIDO  │  │ RECLASIFICADO│
       └────┬─────┘    └──────┬───────┘  └──────┬───────┘
            │ reabrir         │ asignar          │ asignar
            ▼                 ▼                  ▼
       ┌──────────────────────────────────────────────┐
       │                  ASIGNADO                    │
       └─────────────────────┬────────────────────────┘

               ┌─────────────┼─────────────┐
            actualizar    cancelar       archivar
               │             │              │
               ▼             ▼              ▼
       ┌────────────┐ ┌───────────┐ ┌──────────────┐
       │ ACTUALIZADO│ │ CANCELADO │ │  ARCHIVADO   │
       └────────────┘ └───────────┘ └──────────────┘
cancelar and archivar are terminal states — no further transitions are possible from them.

Operations reference

Endpoint: POST /tickets/crearWho can perform it: Anyone (no authentication required).Creates a new ticket and assigns it the NUEVO state. The requester provides their contact details, ticket type, category, priority, and description. The API calls fn_crear_ticket internally and returns the ticket_uuid, ticket_label, SLA deadline, and initial state.Required fields include: nombre, email, tipo, categoria, descripcion, prioridad.
Endpoint: POST /tickets/{ticket_id}/asignarWho can perform it: ADMIN, MESA.Moves the ticket from NUEVO (or back from TRANSFERIDO / RECLASIFICADO) to ASIGNADO. Use this to associate the ticket with a specific agent or area so work can begin.
Endpoint: POST /tickets/{ticket_id}/transferirWho can perform it: ADMIN, MESA.Reassigns the ticket to a different area when the original assignment was incorrect or the ticket needs handling by another team. Sets the state to TRANSFERIDO. Call asignar afterwards to put it back into ASIGNADO.
Endpoint: POST /tickets/{ticket_id}/reclasificarWho can perform it: ADMIN, MESA.Updates the ticket’s classification (type, category, subcategory, or priority) when the original submission was inaccurate. Sets the state to RECLASIFICADO. Call asignar afterwards to resume processing.
Endpoint: POST /tickets/{ticket_id}/pausarWho can perform it: ADMIN, MESA, AREA.Pauses work on the ticket, for example while waiting for a response from the requester or a third party. Sets the state to PAUSADO. SLA tracking behaviour during a pause depends on your system configuration.
Endpoint: POST /tickets/{ticket_id}/reabrirWho can perform it: ADMIN, MESA.Resumes a ticket that was previously paused. Returns the ticket to ASIGNADO so work can continue.
Endpoint: POST /tickets/{ticket_id}/actualizarWho can perform it: ADMIN, MESA, AREA.Records an update or progress note against the ticket without changing its core state. Use this to log actions taken, attach references, or communicate status changes internally.
Endpoint: POST /tickets/{ticket_id}/cancelarWho can perform it: ADMIN, MESA, AREA.Closes the ticket without resolving it. Use this when the request is invalid, a duplicate, or withdrawn by the requester. This is a terminal state — the ticket cannot be reopened after cancellation.
Endpoint: POST /tickets/{ticket_id}/archivarWho can perform it: ADMIN, MESA, AREA.Archives the ticket after it has been resolved. This is a terminal state — use it to mark tickets as fully complete and remove them from active queues.

Operations by role

OperationADMINMESAAREA
crearpublicpublicpublic
asignar
transferir
reclasificar
reabrir
actualizar
pausar
cancelar
archivar
AREA users are additionally restricted by area scoping — they can only act on tickets that belong to their own area, even for the operations listed above.

Looking up a ticket (public)

Requesters do not need an account. They can check the status of their ticket using the ticket_label returned at creation:
POST /api/tickets/consultar
Content-Type: application/json

{
  "label": "TK-2024-00042",
  "email": "[email protected]"
}
The response includes the current state, assigned area, and SLA information without exposing internal IDs.

Build docs developers (and LLMs) love