Documentación de la API

Workflow WF16. Valida credenciales contra la tabla usuarios y, si son correctas, emite el token de sesión firmado (HMAC) que el resto de la API exige.

Body

{ "username": "usuario@ejemplo.com", "password": "..." }

Respuesta 200 (éxito)

{
  "success": true,
  "user": {
    "id": "uuid",
    "username": "usuario@ejemplo.com",
    "nombre": "Ana García",
    "email": "usuario@ejemplo.com",
    "rol": "admin | user",
    "token": "<userId>|<exp>.<hmac>",
    "permisos": { "read": [...], "write": [...], "delete": [...] }
  }
}

Verifica que la sesión sigue viva (chequeo periódico del portal). Un 401/403 fuerza logout.

Gestión de usuarios y roles (Administración → admin.html). auth/usuarios lista/crea/edita/borra usuarios y sus permisos; auth/roles gestiona los roles base. Acciones vía action en el body. El rol se calcula como base + deltas granulares { read, write, delete }.

Workflow 04-fichas-alta. Devuelve la lista completa de fichas (con su cs_estado del Kanban CS). Alias en config.js: ENDPOINTS.login · ENDPOINTS.altas.

Respuesta 200

{
  "clientes": [
    {
      "id": "uuid",
      "denominacion": "Test SL",
      "cif": "B40597437",
      "email": "contacto@test.es",
      "tipo_cliente": "lite | planes | corporate",
      "estado": "rellenado | completada",
      "cs_estado": "en_implementacion | post_primer_mes | ...",
      "grabado_a3": false,
      "grabado_a3_at": null,
      "introducido_yurest": false,
      "promocion_id": null,
      "fecha_solicitud": "2026-04-17T...",
      "fecha_rellenado": "2026-04-17T...",
      "fecha_completado": "2026-04-17T...",
      "sepa_mandato": { ... },
      "adjuntos": [ ... ],
      "paquetes_carrito": { ... },
      "deleted_at": null
      // ... resto de columnas
    }
  ]
}

El workflow excluye filas con deleted_at != NULL. Devuelve todas las columnas, incluidas las vacías como "".

Workflow 04-fichas-alta. Crea una ficha nueva (sin id) o actualiza una existente (con id). En modo edición solo actualiza los campos enviados — no destruye los demás.

Body (todos opcionales en edición)

Respuesta 200 (éxito)

{ "id": "uuid-de-la-ficha", "success": true }

Respuesta 200 (error en INSERT Locales)

{ "error": "..." }

El nodo INSERT Locales tiene continueOnFail: true, así que un fallo en locales no rompe el INSERT/UPDATE de la ficha principal pero sí aparece en el body.

Workflow 12-completar-ficha. Devuelve los datos de una ficha o solicitud para precargar el formulario. Acepta tres formas de identificación.

Query params

Respuesta 200 (encontrado)

{
  "found": true,
  "id": "uuid",
  "ID Solicitud": 5,
  "Nombre Sociedad": "Test SL",
  "Email": "contacto@test.es",
  "Tipo Cliente": "planes",
  "SEPA": { "iban": "ES...", "deudor": {...}, "firma_base64": "..." },
  // ... resto de campos
}

Respuesta 200 (no encontrado)

{ "found": false, "error": "Solicitud no encontrada" }

Workflow 10-eliminar. Soft-delete (UPDATE deleted_at = NOW()) en fichas_alta y solicitudes. Como los UUIDs son únicos entre tablas, sólo afecta a la que contiene el ID.

Body

{
  "action": "delete",
  "entity": "ficha" | "solicitud",
  "id": "uuid",
  "row_number": "uuid"   // alias por compat
}

Respuesta 200

{
  "success": true,
  "entity": "ficha",
  "id": "uuid",
  "ficha_count": 1,
  "sol_count": 0,
  "errores": []
}

Acciones puntuales sobre una ficha ya creada (no re-guardan la ficha entera). Todas reciben { ficha_id } y devuelven { ok, ... }.

Modal «Ver cliente» (clientes.html): notas internas, movimiento en el Kanban CS y asignación de promoción.

Workflow WF-132. Pestaña HighLevel del importador de clientes (importador-clientes.html). Solo lee de HighLevel y del portal: la ficha la guarda después el flujo normal (guardarFicha). La conversión HL → ficha es js/lib/parse-ficha-hl.js, inlineada en el workflow.

Workflow 08-solicitudes. Inserta solicitud en estado pendiente y envía email al cliente con la URL del formulario.

Body

{
  "ID Solicitud": 5,
  "access_token": "32-chars-uuid-sin-guiones",
  "Nombre Sociedad": "Empresa SL",
  "Nombre": "Ana García",
  "Email": "ana@empresa.com",
  "Consultor": "Nombre Consultor",
  "Tipo Cliente": "planes",
  "Fecha": "2026-04-17",
  "Estado": "Pendiente",
  "email_to": "ana@empresa.com",
  "email_subject": "Solicitud de creación de ficha de alta",
  "email_body": "Hola Ana, te mando este formulario...",
  "form_url": "https://.../solicitud.html?t=..."
}

Si access_token no viene, el workflow lo genera con crypto.randomUUID().

Respuesta 200

{ "id": "uuid", "success": true }

Listados y utilidades del flujo de solicitudes.

Workflow 11-auxiliares. El cliente envía sus datos desde solicitud.html. Crea la ficha, carpeta Drive, marca solicitud completada y dispara emails + tarea Asana si TPV no integrado.

Body (todos los datos del formulario)

{
  "ID Solicitud": 5,
  "access_token": "...",
  "Estado": "Rellenado cliente",
  "Nombre Sociedad": "...", "CIF/NIF": "...",
  "JP Nombre": "...", "Firmante DNI": "...",
  "TPV": "Revo",
  "TPV No Integrado": "Sí",  // si checkbox marcado
  "TPV NI Nombre": "...", "TPV NI Contacto": "...", "TPV NI Email": "...",
  "SEPA": {
    "iban": "ES91...",
    "swift": "CAIXESBB",
    "deudor": { "nombre": "...", "direccion": "...", ... },
    "tipo_pago": "recurrente",
    "firma_base64": "data:image/png;base64,...",
    "firmado_at": "2026-04-17T..."
  },
  "Contactos Extra": [   // opcional, máx 10: otras personas de la implementación (paso 03)
    { "nombre": "...", "apellidos": "...", "puesto": "...", "email": "...", "telefono": "..." }
  ]
}

Efectos

• INSERT en fichas_alta con estado=completada + SEPA persistido.
• Crea carpeta en Google Drive y guarda carpeta_drive en la ficha.
• Email al cliente con enlace al Drive.
• Email al consultor avisando.
• UPDATE solicitudes: estado=completado + ficha_id (dispara trigger que copia fecha_solicitud).
• Si TPV no integrado: tarea en el proyecto de Integraciones de Asana + email al equipo de soporte e integraciones.
• Contactos Extra → lista de contactos del cliente (RPC contactos_cliente_importar): deduplica por email, no pisa ninguno existente, ignora el del jefe de proyecto y los deja con convocar = true. Al crearse el proyecto, un trigger los copia a proyectos.contactos.

Respuesta 200

{ "success": true }

Workflow 30-ofertas. Ofertas generadas por el configurador (departamento Consultor). GET lista con filtros; ?id=<uuid> devuelve una sola.

POST — action

Workflow 55-pasarela (Redsys/BBVA). El cliente, desde la oferta pública, pulsa «Pagar».

POST /pago/iniciar

// Request
{ "token": "<token-oferta>" }

// Respuesta — el front auto-submitea un form a Redsys
{
  "ok": true,
  "redirect": {
    "url": "https://sis.redsys.es/...",
    "Ds_SignatureVersion": "HMAC_SHA256_V1",
    "Ds_MerchantParameters": "<base64>",
    "Ds_Signature": "<firma>"
  }
}

El importe es final_amount × 1,21 (IVA). La firma Redsys (HMAC_SHA256_V1, 3DES en JS puro) y el inserto en payments se hacen server-side. La notificación S2S y las páginas OK/KO las sirve el propio workflow. /pago/enviar-ficha-link reenvía al email del cliente el enlace de su solicitud («Continuar más tarde»).

Workflow WF26. Ampliaciones contractuales sobre clientes existentes (módulos, locales o firmas). GET lista; POST crea o cambia el estado.

Filtros del GET, todos opcionales: ?ficha_id=<uuid> · ?tipo=modulo|local|firmas · ?estado=solicitado|pendiente|aplicado|cancelado · ?incluir_archivados=1 (los soft-deleted salen al final). Orden: pendientes primero y, dentro, más recientes primero.

detalle según tipo

modulo: { modulos[], locales_ids[], setup, recurrencia, periodicidad:'mensual'|'anual' }
local:  { local:{ nombre, … },
          sepa:{ modo:'existente', mandato_id } | { modo:'nuevo', iban, bic, titular, sociedad_cif, sociedad_denominacion },
          modulos[], setup, recurrencia, periodicidad:'mensual'|'anual' }
firmas: { packs, firmas, setup, recurrencia }

Respuesta 200

{ "success": true, "escalado": { … }, "errores": [] }

solicitar y reenviar añaden email_enviado (bool) y email_error. El escalado queda guardado aunque el correo falle; el front ofrece entonces «Copiar enlace» o «Reenviar».

Workflow WF-142. Formulario del cliente escalado-local.html?t=<token> para un escalado de local en solicitado. Sin sesión: lo autoriza el token del escalado (64 hex). Las reglas (token, estado, caducidad de 30 días desde el último envío, validación) viven en SQL: escalado_local_solicitud() y escalado_local_responder(), migración 2026-10-19_02.

datos

{ local:    { nombre, email?, telefono?, calle, numero?, cp, municipio, provincia },
  contacto: { nombre, puesto?, email, telefono },
  tpv:      { nombre, no_integrado?, contacto?, email? },
  sepa:     { modo:'existente', mandato_id }
          | { modo:'nuevo', iban, titular, bic?, cif, denominacion, firma } }

Workflow 13-grabado-a3. Toggle del flag grabado_a3 en una ficha. Trigger SQL setea grabado_a3_at al pasar de FALSE a TRUE.

Body

{ "id": "uuid", "grabado_a3": true | false }

Respuesta 200

{
  "success": true,
  "id": "uuid",
  "grabado_a3": true,
  "affected": 1,
  "errores": []
}

Workflow 39. Lectura de Azure SQL (yurestazure / Info_PowerBI). La página pinta una tabla genérica con auto-detección de columnas; la query se ajusta en n8n (la página no envía SQL).

Respuesta 200

{ "ok": true, "total": 120, "columnas": [...], "rows": [...], "generated_at": "ISO" }

Workflow WF137 (14-oct-2026). Cruce de lo facturado en A3 con el portal, HighLevel y producto (cruce-a3.html, permiso cruce_a3). Devuelve la última foto guardada en a3_cruce_snapshot: → { ok, generado_at, corte, datos }, o { ok, datos:null } si aún no hay.

Workflow WF102. Facturas emitidas al cliente, que este ve en su Espacio Cliente. El PDF vive en un bucket privado: el listado nunca devuelve storage_path.

Workflow WF99. Facturas que los distribuidores emiten a Yurest por sus comisiones. Viven en la BD del portal de distribuidores (schema distribuidores), no en la de yurest: WF99 es el único que las toca, con la service key guardada en n8n.

Workflow 01-proyectos-crud. CRUD de proyectos de implementación.

El POST/PUT acepta asanaProjectId y asanaProjectUrl para vincular un tablero Asana.

Qué trae cada proyecto en el GET

El GET devuelve los proyectos vivos (los borrados se filtran en la BD desde el 24-oct-2026) y acepta ?id=<uuid> para leer uno solo. Cada fila, completa: id, cliente, implementador, tipo (el «plan»: Basic / Pro / Corporate), estado, fecha_inicio, ultima_actividad, tpv, motivo_pausa, plan_accion, asana_project_id, asana_project_url, promocion_id, promocion_turno, ficha_id, origen_secciones, meta_updated_at y las marcas de tiempo. En JSONB: secciones, orden_secciones, anotaciones (bitácora), contactos, participantes, adjuntos y formularios.

Cada objeto de secciones puede llevar además escalado_id y escalado_fecha: el sello que pone WF26 a las secciones que nacen al aplicar un escalado. Su ausencia significa «implementación inicial». Es lo que separa las vistas «Implementación / Escalado N» del tab Proyecto; el progreso y los KPIs no cambian, las secciones de escalado siguen contando en el total.

El detalle de sesiones con sus fechas vive dentro de secciones[].tareas[]: nombre, completada, show (Show / No Show / null), fechaEntrega, tiempoEstimado, notas y subtareas[].

ultima_actividad vs ultima_actividad_efectiva

La columna ultima_actividad solo la escriben este workflow (alta y PUT) y WF02 al guardar o mover una tarea. No la tocan el panel de sesiones (WF52, donde se marcan Show / No Show), el espejo de Asana (WF81) ni el importador de tareas de promoción (WF83), así que se queda vieja en cuanto las sesiones se marcan fuera del gestor.

Por eso el GET añade ultima_actividad_efectiva: el máximo entre esa columna y la fecha de la última sesión realmente dada (tarea o subtarea completada o marcada Show / No Show, con fechaEntrega en pasado; agendar a futuro no cuenta). Se calculan sobre las mismas secciones que el progreso: fuera las administrativas, Hardware, «Módulos terminados de implementar» y las marcadas descontratado.

Token de solo lectura (consultas automatizadas)

El GET de este endpoint —y solo el GET— acepta además un token de solo lectura, pensado para informes que corren sin que nadie tenga la sesión abierta en el navegador. Va en la misma cabecera que la sesión de staff:

curl -H "X-Session-Token: ro|informe-semanal|1788000000000.<hmac>" \
     {BASE_URL}/proyectos

Se firma con un secreto distinto del de las sesiones. Ese es justo el mecanismo de seguridad: para los demás webhooks el token es una firma inválida, así que devuelven 401 sin que haya hecho falta cambiar nada en ellos. Un token de lectura filtrado no abre escritura ni ningún otro endpoint.

Workflow 02-proyectos-tareas. Actualiza una tarea/sección dentro de un proyecto (toggle completada, edición, etc.).

Body

{
  "proyectoId": "uuid",
  "seccionNombre": "Puesta en Marcha / Finalización",
  "tarea": { "id": "...", "completada": true, "_v": "versión que se cargó", ... },
  "comprobarVersion": true
}

Respuesta 200

{ "success": true, "version": "2026-10-24T17:46:13.544670Z" }

Respuesta 409 (otra persona guardó la tarea después)

{ "success": false, "code": "conflict", "error": "Otro usuario guardó esta tarea…", "version": "versión vigente" }

Mover una tarea entre secciones (drag & drop kanban) o eliminarla.

Body — mover

{ "proyectoId": "uuid", "tareaId": "...", "seccionOrigen": "...", "seccionDestino": "..." }

Hilo cliente ↔ staff e historial del proyecto (WF01).

Acciones puntuales sobre un proyecto que no reescriben el proyecto entero.

Pestaña «Comunicaciones automáticas» de Proyectos y de la Cascada CS: lo que el portal ha mandado al cliente (tabla comunicaciones_cliente).

WF-139. Menciones «@usuario» en las anotaciones (bitácora) de Proyectos y de la Cascada CS, y su aviso en el panel de alertas del escritorio. La regla vive en SQL (menciones_accion, tabla menciones, migración 2026-10-15_02): la bitácora es la misma en proyectos y cs_kanban, así que se puede mencionar a quien entra (cualquier nivel) en cualquiera de las dos, y a los comerciales (usuarios activos con rol Consultor) aunque no entren en ninguna (16 y 20-oct-2026); admin entra en todas. Quien escribe sí necesita acceso a la página. La mención se guarda con la página por la que entra el mencionado. La entrada guarda menciones:[{ id, nombre }] en proyectos.anotaciones.

Workflow WF-101. Accesos multiusuario al Espacio Cliente de un proyecto. Solo staff.

Proxy e importadores de Asana (las credenciales viven solo en n8n).

Tandas de implementación (Customer Success): 16 plazas (8 mañana + 8 tarde). Doble proyecto Asana por promoción.

Sesiones de las promociones grupales y su convocatoria en Google Calendar.

Workflow 07-calendar-asana. Google Calendar del implementador.

Panel de sesiones de implementación (panel-sesiones.html; workflows WF52 y WF53 para los dashboards). Ojo: estas rutas validan el token de sesión en Authorization: Bearer <token>, no en X-Session-Token. Las rutas con id usan query param (/api/tasks/<gid> → /panel/tasks?gid=).

Workflow WF-99. Sesiones privadas agendadas por nosotros (clientes.html → Formación). Mismo motor de huecos que el Espacio Cliente, pero con sesión de staff y sin veto por cuota: aquí la cuota se enseña y decide quien agenda.

Workflow WF-138 (15-oct-2026). El cliente grupal agenda sus dos sesiones privadas de la promoción («Sesión Privada de Seguimiento», 30 min, y «Sesión Privada», 1 h) con el implementador de su promoción, desde agendar-sesion.html?t=<token> (enlace de los correos de la promoción). Sin sesión: lo autoriza el token del proyecto (tabla agenda_privadas_tokens). Qué está pendiente, la caducidad y la escritura en el proyecto viven en SQL (agenda_privadas_estado() / agenda_privadas_reservar(), migración 2026-10-15_02).

Workflow WF-100. Participación en sesiones por promoción (participacion.html).

El implementador marca Show / No Show a mano. «Guardar y enviar» pide la vista previa del correo (WF-130) y, si se confirma, WF96 lo envía; «Guardar» a secas no llama aquí. Los dos reciben el mismo body.

Body

{ "ficha_id": "uuid", "tarea_id": "...", "motivo": "..." | null, "nota": "..." | null,
  "recupera": { "fecha": "YYYY-MM-DD", "hora": "HH:mm" | null } }   // opcional: se recupera en otra sesión ya agendada

Respuesta de /preview (no envía ni escribe nada)

{ "ok": true,
  "correos": [{ "destino": "jp@cliente.es", "cc": "...", "asunto": "...", "html": "..." }],
  "otros":   [{ "tipo": "noshow_3_pausa" } | { "tipo": "reasignacion_promo", "fecha_destino": "YYYY-MM-DD", "turno_destino": "manana|tarde" }],
  "motivo":  "ya_enviado | sin_ausencias | sin_ficha" }   // solo cuando no hay correo

Sesión de bienvenida grupal con la CSM, reservada por el cliente desde solicitud.html o bienvenida.html?t=. Un evento de Google por hueco. Cupos y antelación (36 h) viven en SQL; un cron cada 15 min revisa rechazos y cancelaciones en Google, manda el recordatorio de 24 h y el correo de no-show, y reenvía el Meet si cambia.

Workflows WF-97 (rebuild) y WF-98 (lectura). Estado de la carga de datos de los clientes. Mismo par que los snapshots de Soporte: un cron reconstruye, el GET sirve lo último guardado.

Workflow WF-104. Informe semanal de seguimiento de implementaciones. Calcula en servidor lo mismo que manda el correo de los lunes a Operaciones, así que la pantalla (informe-seguimiento.html) y el correo no pueden divergir. Sin parámetros.

Workflow «112 - Checklists (IA + API Yurest)». Backend del Configurador de checklists (checklists.html, Implementación → Configuradores).

Workflow «140 - Configurador recetas (IA)» (lvfFVRT3q8Vgn134). IA del Configurador de recetas (configurador-recetas.html, Implementación → Configuradores), que llegó como artifact de Claude: sustituye a window.claude.use('sample'). Credencial «Anthropic API (bot ayuda)».

WF-145 «Recetas Historial». Copias en el servidor del trabajo del Configurador de recetas (el mismo JSON que guarda en localStorage), para rescatar o consultar las fichas de un cliente desde cualquier equipo. La regla vive en SQL (recetas_historial_accion, tabla recetas_historial, migración 2026-10-20_03): entra quien tiene el permiso configurador_recetas (o admin) y el historial es de todo el equipo. El front guarda solo al exportar, antes de «Nuevo cliente» y antes de restaurar otra copia.

Desarrollos a medida por cliente (reemplaza el Excel de Producto).

Workflow WF66. Horas contratadas vs consumidas por cliente. Las contratadas se registran como compras (cantidad + PDF pago + PDF factura); las consumidas se derivan de los presupuestos aceptados/pagados.

Workflow WF57. Lee en vivo el proyecto Asana «Sugerencias optimizaciones clientes» (tareas + secciones + etiquetas + campos, normalizado y paginado).

Workflows WF-106 (Asana) y WF-107 (vacaciones). El tablero mensual «Sprint #N - <nombre>» de Producto, leído y escrito en vivo contra Asana. Lo usa triaje-sprint.html.

Workflow WF-110. Productividad por desarrollador (productividad.html, permiso triaje_sprint).

Workflow WF-111. Informe de errores de sprint (errores.html, permiso triaje_sprint).

Workflow WF-115. Vista Tareas Asana de Producto (tareas-asana.html, permiso tareas_asana). Proyecto Back Clientes, solo tareas abiertas de las secciones Pendiente de revisión, Pendiente de presupuesto, Necesita más info y Aprobadas.

Base de conocimiento de sprints (gpt-4o). Se pega la URL de un proyecto Asana, se elige un campo enum y sus valores, y se genera un documento markdown de las funcionalidades del sprint.

Workflow WF73. Newsletter de sprint (/updates). Analiza un proyecto Asana, reescribe títulos con IA y arma el email.

Workflow WF-118. Backend de la Cascada CS (clientes.html → Customer), los paneles cs-inicio · cs-actividad · cs-kpis y la pestaña Contactos del gestor. El workflow solo valida la sesión y llama a funciones SQL (cs_ficha, cs_resumen, cs_agenda, cs_actividad, cs_kpis, cs_tareas_impl, cs_accion): la lógica vive en la base de datos. El autor de cada acción sale del token, nunca del body.

GET /cs?recurso=…

POST /cs/accion

{ "accion": "contacto_cliente_crear",
  "datos": { "ficha_id": "uuid", "nombre": "Ana", "apellidos": "", "rol": "Gerente", "email": "ana@cliente.es", "telefono": "", "convocar": true } }

Respuesta

{ "ok": true, ... }
{ "ok": false, "code": "validacion | sin_usuario | sin_permiso | no_encontrado | conflicto | transicion | duplicado | accion_desconocida", "error": "texto legible" }

Integración HighLevel (CRM). Credenciales (LOCATION_ID + TOKEN) solo en n8n.

Workflow WF76. Clientes Free 3 meses. GET lista clientes_free_3m; /toggle persiste Free(0)/Lite(1); /refresh re-sincroniza contra HighLevel sin esperar al cron de las 6.

Resumen del día para el dashboard del home. GET sin parámetros → { fecha, ofertas, fichas, bajas, escalados } (contadores incrementales de home_kpis_diarios, mantenidos por triggers AFTER INSERT).

Workflow WF-117. Contadores de los badges del menú calculados en el servidor, para que el home no tenga que bajarse /altas completo (3,6 MB → 161 B). Sin parámetros.

{
  "version": 1,
  "a3": 12,
  "sinasignar_ids": ["…"],
  "sinasignar_sin_id": 0,
  "proformas": 3,
  "hardware": { "lista_envio": 2, "solicitada": 1 }
}

Workflow WF105. Informe mensual de KPIs de soporte: una fila por mes en informes_mensuales_soporte. El cron del día 1 lanza las 52 consultas a la Search API de Zendesk del mes anterior y guarda el informe ya redactado. Lo consume informe-mensual-soporte.html.

Asociación cliente ↔ organización Zendesk (modal «Ver cliente» → Tickets) y registro de errores.

Workflow WF07. Actividad de un ticket Zendesk desde la tarjeta de integraciones.html.

Snapshots diarios (06:00) + refresco manual. Cruce Zendesk × Asana.

Pestaña Formación · proyecto Asana asociado al cliente.

Mini-app «Churn técnico» (iframe). Webhooks autenticados por el Auth Gate HMAC: churnClientes, churnResumenGenerar, churnNiveles, churnResumenBuscar, churnTickets.

Notificaciones automáticas de Integraciones: configuración, grupos de destinatarios e historial de envíos.

Uso del producto Yurest cacheado en Supabase (prod_clientes_snapshot) para evitar la query pesada al MySQL de producción en cada apertura.

Workflow WF91. «Mis contraseñas»: gestor de credenciales de portales externos. El servidor resuelve userId y rol del token; un no-admin solo ve/edita las suyas, el admin todas.

Workflow WF92. «Mi equipo»: inventario por persona. Jerarquía tipo(sección) → catálogo(modelo, coste solo-admin) → unidad(física asignada a un usuario).

Audit log.

Tareas de cocina (tareas-cocina.html, autoservicio).

Gestión documental (documentos-rrhh.html): NDA y cesión de equipos en PDF por empleado. Quién ve qué lo decide la base de datos: el gestor ve a todos; el resto, solo lo suyo.

Workflow 05-bajas. Gestión de bajas de clientes (registro, edición de campos individuales y borrado).

Workflow WF112 («Bonificaciones CRUD»). Bonificaciones de MRR de la vista Churn (churn.html, permiso bajas).

Workflow 06-distribucion. Asigna un implementador a una ficha.

Body

{ "fichaId": "uuid", "implementador": "Nombre Implementador" }

Workflow WF78. Distribuidores potenciales: cuando el consultor rellena el TPV de un local y su email de contacto, el workflow saca el dominio y, si no consta como distribuidor conocido, avisa al responsable de distribuidores y registra la fila.

Workflow 11-auxiliares. getDrive devuelve la URL de la carpeta Drive de una ficha; docsSubidos consulta si hay documentos subidos.

Query

?id=<ficha_uuid>

Alta de contraseña, login y recuperación. Los accesos los crea el staff desde portal-accesos (WF-101).

Pedidos de hardware desde el Espacio Cliente (WF77). Sin aviso a Slack: se ven en la pestaña Hardware y en la alerta del home del staff.