> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getnexor.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Automatización avanzada
El hub **Avanzado** reúne las capacidades para conectar Nexor con otros sistemas, enrutar leads y ejecutar automatizaciones fuera del flujo conversacional normal. Se abre desde **Avanzado** en la barra lateral y su configuración aplica a toda la organización, salvo cuando una herramienta se asigna explícitamente a un agente.
Envía eventos firmados a un endpoint HTTP.
Permite que los agentes consulten APIs y ejecuten acciones durante una conversación.
Automatiza cohortes de leads con filtros, pasos y protecciones.
Decide a qué agente entra cada lead antes de iniciar una ejecución.
Ejecuta JavaScript cuando ocurre un evento de Nexor.
Ejecuta JavaScript sobre un grupo de leads según un cron.
Comparte secretos de solo escritura con funciones y herramientas.
## Elige la capacidad correcta
| Necesidad | Usa | Por qué |
| ------------------------------------------------------------------------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| Entregar un evento de Nexor a un servicio que ya tiene un endpoint | Webhook | Envía un callback firmado sin ejecutar lógica propia en Nexor. |
| Consultar o modificar un sistema mientras el agente conversa | Herramienta MCP | El modelo decide cuándo llamarla y completa sus argumentos con el contexto de la conversación. |
| Ejecutar una secuencia estructurada sobre leads filtrados | Background Job | Ofrece filtros, condiciones, acciones, límites y modo simulación sin escribir un programa completo. |
| Enrutar un lead entrante a uno de varios agentes | Pre-procesador | Evalúa reglas ordenadas antes de crear la ejecución del agente. |
| Transformar un evento, llamar varias APIs o actualizar el lead con código | Cloud Function | Ejecuta JavaScript aislado con el payload completo del evento. |
| Procesar periódicamente una cohorte con lógica en código | Scheduled Function | Combina cron, zona horaria, consulta de leads y JavaScript aislado. |
| Guardar tokens, API keys o URLs sin exponerlos en el código | Variable de entorno | Las funciones leen `env.NAME` y las herramientas MCP resuelven `{{env.NAME}}`; la interfaz no vuelve a mostrar el valor. |
Estas capacidades se pueden combinar. Un patrón común es **Pre-procesador → Agente con herramientas MCP → Webhook o Cloud Function → Background Job de seguimiento**.
## Webhooks
Los Webhooks envían notificaciones HTTP salientes cuando ocurre un evento compatible de estado, reunión o contacto. Cada request incluye una firma HMAC en `X-Nexor-Signature`, por lo que el receptor puede comprobar que el payload proviene de Nexor.
Úsalos cuando tu sistema solo necesita recibir el evento. Si debes filtrar, transformar, bifurcar, llamar a varios servicios o escribir datos de vuelta en el lead, usa una Cloud Function.
Antes de activar un webhook:
1. configura la URL y los eventos;
2. guarda el signing secret en el sistema receptor;
3. verifica la firma sobre el body sin modificar;
4. responde rápido con un código `2xx`; y
5. procesa de forma idempotente porque una entrega puede reintentarse.
Consulta [Eventos de Webhooks](/docs/es/api/webhooks/overview), [Verificar firmas](/docs/es/api/webhooks/verifying-signatures) y [Reintentos y errores](/docs/es/api/webhooks/retries-and-errors).
## Herramientas MCP
Una herramienta MCP describe una llamada HTTP que el agente puede hacer durante la conversación. La definición incluye nombre, descripción, método, URL, esquema JSON de parámetros, headers, autenticación, timeout y reglas para interpretar la respuesta.
Las **Herramientas MCP** de este hub permiten que un agente de Nexor llame a tus sistemas. El [Servidor MCP de Nexor](/docs/es/api/mcp-server) hace lo inverso: permite que Claude, Cursor, Codex u otro cliente de IA administre Nexor.
Hay dos alcances:
* **Catálogo global:** una herramienta reutilizable que se asigna a varios agentes.
* **Herramienta del agente:** una integración de una sola vez, disponible únicamente para ese agente.
Después de asignarla, puedes decidir si el agente la llama cuando la necesita, si se ejecuta automáticamente al entrar el lead, si queda disponible solo en ciertas etapas o si corre como acción automática al entrar a una etapa. Consulta [Avanzado del agente](/docs/es/guides/agents/settings#avanzado-del-agente) para estas políticas.
Una descripción imprecisa o un esquema demasiado permisivo hace que el agente llame la herramienta en el momento equivocado. Describe el efecto, las condiciones de uso y cada argumento; guarda las credenciales en **Variables de entorno** y refiérelas como `{{env.MY_KEY}}` en lugar de escribir secretos en la definición.
Para administrar herramientas por API, consulta [Client Tools](/docs/es/api/client-tools/list-client-tools) y [Workflow Tools](/docs/es/api/workflow-tools/list-workflow-tools).
## Background Jobs
Los Background Jobs ejecutan automatizaciones estructuradas sobre leads. Pueden dispararse por **cron**, por un **evento compatible** o solo mediante la **API**.
Un job combina:
* filtros por agente, estado y datos del lead;
* condiciones sobre metadata, variables o tags;
* acciones como asignar o transferir un agente, cambiar el estado, enviar un template de WhatsApp o llamar una API externa;
* límites de leads por ciclo, cooldown y rate limit;
* exclusión de leads tomados por una persona o con el agente pausado;
* modo simulación y registros por ejecución.
Empieza con **Modo simulación**, revisa cuántos leads serían candidatos y qué acciones se ejecutarían, y luego actívalo con límites conservadores. Usa **Ejecutar ahora** solo después de validar la misma configuración.
Consulta la [API de Background Jobs](/docs/es/api/background-jobs/list-background-jobs) para crear, ejecutar e inspeccionar jobs de forma programática.
## Pre-procesadores
Los Pre-procesadores enrutan leads antes de que entren a un agente. Cada procesador tiene reglas ordenadas y un agente predeterminado:
1. recibe un lead mediante el endpoint del procesador;
2. evalúa las reglas de arriba hacia abajo usando campos de primer nivel y `metadata`;
3. usa la primera regla que coincide; y
4. envía el lead al agente predeterminado si ninguna coincide.
Son útiles para distribuir por país, línea de negocio, campaña, producto, tamaño de cuenta o cualquier dato disponible al momento de crear el lead. El endpoint también acepta lotes; cada lead se evalúa de forma independiente y puede terminar en un agente distinto.
Consulta [Crear un Pre-procesador](/docs/es/api/processors/create-processor), [Crear una regla](/docs/es/api/processors/create-rule) y [Enrutar un lead](/docs/es/api/processors/route-lead).
## Cloud Functions
Las Cloud Functions ejecutan JavaScript aislado cuando ocurre uno de los eventos del agente. El código recibe el payload en `ctx`, puede consultar `lead`, hacer requests con `axios` o `fetch`, registrar logs, devolver JSON y proponer cambios con `updateLead` o `updateMetadata`.
Cada función escucha un solo trigger. Simula el payload, guarda para desplegar y revisa las ejecuciones antes de activarla. Las llamadas HTTP de una prueba manual son reales aunque los cambios propuestos al lead no se apliquen.
Consulta la [guía completa de Cloud Functions](/docs/es/guides/advanced/cloud-functions) para ver triggers, runtime, límites, ejemplos y logs.
## Scheduled Functions
Las Scheduled Functions ejecutan JavaScript aislado según una expresión cron y una zona horaria. En cada ejecución consultan una cohorte de leads, exponen el contexto del batch al código y registran el resultado y los logs.
Úsalas cuando la lógica es demasiado específica para un Background Job: agregaciones, payloads personalizados, llamadas coordinadas a varias APIs o reglas que conviene expresar en JavaScript. Antes de activar una función:
1. define el cron y la zona horaria;
2. limita la consulta a la cohorte necesaria;
3. previsualiza los leads incluidos;
4. ejecuta una prueba con credenciales y endpoints seguros; y
5. revisa los logs y diseña las escrituras para que sean idempotentes.
Un Background Job expresa filtros y pasos en una estructura administrada. Una Scheduled Function entrega control de código. Elige la primera cuando sus acciones cubran el caso; usa código cuando necesites una transformación o integración propia.
## Variables de entorno
Las Variables de entorno guardan secretos compartidos por Cloud Functions, Scheduled Functions y herramientas MCP. En las funciones se leen como `env.NAME`, por ejemplo `env.CRM_API_TOKEN`. En la autenticación, headers o query params de una herramienta MCP se referencian como `{{env.NAME}}`.
Los valores son de solo escritura: después de guardar un secreto, la interfaz muestra el nombre pero nunca el valor. Reemplazar una variable exige ingresar el valor completo nuevamente. Los nombres deben comenzar con una letra mayúscula y usar solo mayúsculas, números y guiones bajos.
Eliminar o reemplazar un secreto puede romper varias funciones a la vez. Busca el nombre en el código, actualiza primero el sistema externo cuando corresponda y revisa los despliegues y logs después del cambio.
Una organización puede guardar hasta 128 variables, con nombres de hasta 64 caracteres y valores de hasta 5 KiB.