Recuperar el blueprint actualmente aplicado a un ticket de Zoho Desk es una única solicitud GET autenticada — no se requiere cuerpo, solo un ID de ticket válido y los ámbitos OAuth correctos.
Por qué esto es importante
Los blueprints en Zoho Desk imponen flujos de trabajo estructurados sobre los tickets, controlando qué transiciones pueden realizar los agentes y qué datos deben capturarse en cada etapa. Cuando desarrollas integraciones, automatizaciones o herramientas de auditoría, a menudo necesitas inspeccionar el estado activo del blueprint en un ticket específico — por ejemplo, para determinar qué botones de transición deben mostrarse en un portal personalizado, o para registrar la etapa actual con fines de cumplimiento. Esta guía (de Beam Help — soporte experto independiente para Zoho, no soporte oficial de Zoho) te explica exactamente cómo hacerlo a través de la API REST de Zoho Desk.
---
Paso a paso
Paso 1. Confirma que tus ámbitos OAuth están configurados.
Antes de realizar cualquier llamada a la API, verifica que tu token OAuth incluya los ámbitos de ticket de Zoho Desk necesarios. Como mínimo, necesitas Desk.tickets.READ en tu lista de ámbitos autorizados — ámbitos de ticket más amplios como Desk.tickets.ALL también satisfacen este requisito. [5]
Paso 2. Identifica el ID del ticket de destino.
Necesitas el ticketId interno de Zoho Desk del ticket cuyo blueprint deseas inspeccionar. Este es el identificador numérico que se devuelve cuando se crea o lista un ticket — no el número de ticket legible por humanos que se muestra en la interfaz. Si aún no lo tienes, recupéralo de una llamada de listado o búsqueda anterior.
Paso 3. Llama al endpoint "Get Applied Blueprint Details".
Envía una solicitud HTTP GET a la siguiente ruta, sustituyendo tu ID de ticket real:
GET /api/v1/tickets/{ticketId}/blueprint
Incluye tu token bearer OAuth en el encabezado Authorization como de costumbre. Se puede pasar un diccionario de parámetros de consulta opcional (p) si necesitas filtrar o paginar la respuesta, pero en la mayoría de los casos no se requieren parámetros adicionales. [1]
En Python, usando el wrapper del cliente de Zoho Desk, la llamada tiene este aspecto:
result = client.op_7_get_applied_blueprint_details(ticketId="1234567890")
El método emite un GET a /api/v1/tickets/{ticketId}/blueprint y devuelve la respuesta procesada. [1]
Paso 4. Procesa la respuesta.
El cuerpo de la respuesta contiene los detalles del blueprint actualmente aplicado a ese ticket — incluyendo los estados de transición activos y cualquier requisito de campo asociado. Inspecciona el objeto devuelto para encontrar la etapa actual, las transiciones disponibles y los campos obligatorios que deben completarse antes de que pueda realizarse una transición.
Paso 5. (Opcional) Cruza la información con la definición del blueprint.
Si necesitas el esquema completo del blueprint — todas las etapas, todas las transiciones, todas las condiciones — en lugar de solo el estado aplicado en un ticket, puedes obtener la definición del blueprint directamente usando su ID:
GET /api/v1/blueprints/{blueprintId}
Esto devuelve la configuración completa del blueprint independientemente de cualquier ticket específico. [2]
Para descubrir qué blueprints existen en un departamento, también puedes listarlos todos:
GET /api/v1/blueprints
Esto devuelve todos los blueprints configurados en el departamento, lo cual es útil para mapear los IDs de blueprint antes de profundizar en una definición específica. [7]
---
Errores comunes
- Tipo de ID incorrecto. Pasar el número de ticket legible por humanos (p. ej.
#1042) en lugar delticketIdnumérico interno resultará en un error 404 o de registro inválido. Usa siempre el ID generado por el sistema. [1]
- Ámbito OAuth ausente o insuficiente. Si tu token fue generado sin
Desk.tickets.READ(o un ámbito más amplio equivalente comoDesk.tickets.ALL), la API devolverá un error de autorización. Vuelve a generar tu token con los ámbitos correctos incluidos. [5]
- Blueprint no aplicado. Si no se ha aplicado ningún blueprint al ticket, el endpoint puede devolver un objeto blueprint vacío o nulo en lugar de un error. Gestiona este caso de forma adecuada en la lógica de tu integración, en lugar de asumir que siempre hay un blueprint presente. [1]
- Confundir los endpoints de nivel de ticket con los de nivel de definición. El endpoint
/api/v1/tickets/{ticketId}/blueprintdevuelve el estado *aplicado* para un ticket específico, mientras que/api/v1/blueprints/{blueprintId}devuelve la *definición* de un blueprint. Tienen propósitos distintos — no los sustituyas el uno por el otro. [1][2]
---
Qué verificar
- Verificación de ámbitos: Confirma que tu token OAuth activo incluye
Desk.tickets.READoDesk.tickets.ALLantes de realizar la llamada. [5] - ID de ticket correcto: Comprueba que el
ticketIdque estás pasando es el ID interno del sistema, no el número de visualización que aparece en la interfaz de Zoho Desk. [1] - Gestión de la respuesta: Verifica que tu código gestiona el caso en que el campo blueprint esté vacío o sea nulo, lo que indica que actualmente no hay ningún blueprint aplicado a ese ticket. [1]