Cloud Functions

Las Cloud Functions ejecutan tu JavaScript cada vez que ocurre un evento seleccionado de Nexor. Nexor entrega el objeto del evento a tu función como ctx, donde puedes inspeccionarlo y transformarlo, actualizar el lead, llamar a cualquier API HTTP externa y devolver un resultado para el historial de ejecuciones. Usa una Cloud Function cuando una integración necesite lógica personalizada, no solo una copia de un evento. Por ejemplo, puedes adaptar un lead calificado al formato de tu CRM, avisar a un equipo solo sobre conversiones de alto valor o enviar datos de reuniones a tu propio backend sin alojar un procesador de eventos aparte. Si el mismo código debe ejecutarse con una programación cron sobre una cohorte de leads seleccionada, usa una Función programada.

Las Cloud Functions están en Integraciones → Desarrolladores → Cloud Functions. Cada función escucha un trigger, y ese trigger determina la forma de ctx.

Cómo funciona

Ocurre un evento en Nexor, como un cambio de estado de un lead.
Nexor invoca las Cloud Functions activas asociadas a ese trigger.
La función recibe el objeto específico del evento como ctx y se ejecuta en un entorno JavaScript aislado.
Nexor guarda la salida de consola, las solicitudes HTTP, el valor devuelto, los cambios del lead, el estado y la duración en el historial de ejecuciones.

Una función escucha el evento seleccionado en toda tu organización de Nexor. Para limitarla a un agente, estado, canal u otra condición, revisa los campos correspondientes de ctx y termina la ejecución cuando no coincidan. Nexor ejecuta como máximo 25 funciones activas coincidentes por evento; si hay más, las funciones excedentes se omiten. Las Cloud Functions están diseñadas para procesadores de eventos acotados. Cada ejecución puede durar hasta cinco minutos y hacer hasta 20 solicitudes salientes.

Crear una función

En el dashboard, los roles Owner, Admin y Partner de la organización pueden crear, editar, probar, publicar, pausar o eliminar Cloud Functions.

Nombra la función y elige un trigger

Ve a Integraciones → Desarrolladores → Cloud Functions, haz clic en Nueva función, ingresa un nombre descriptivo y selecciona el evento que debe ejecutar tu código.

Revisa el payload

Abre la pestaña Payload del editor. Allí verás un ctx de ejemplo para el trigger seleccionado. Haz clic en un campo para insertarlo en el código y contempla que algunos campos pueden ser null o no estar presentes en un evento real.

Escribe la lógica de integración

Usa los datos del evento, los helpers integrados para leads y axios o fetch para implementar la acción. Agrega API keys, tokens y URLs de endpoints como variables de entorno en vez de colocar secretos en el código.

Guarda y prueba

Una función nueva empieza en pausa, y su primer guardado es la versión 1. Desde ahí, Guardar (⌘S) deja los cambios de código en un borrador. Elige Probar (⌘↵) para ejecutar el borrador con un ctx de ejemplo editable y revisa la salida, las solicitudes, el valor devuelto y los cambios en el lead previsualizados.

Publica, activa y monitorea

Elige Publicar cambios cuando el borrador esté listo, enciende Activa y guarda para ejecutar la versión publicada en cada evento que coincida. Abre Registros para revisar ejecuciones posteriores o pausa la función sin eliminar su código.

El dashboard no permite cambiar el trigger después de crear la función porque define la suscripción al evento y el payload de ctx. Si trabajas solo en el dashboard, crea una función nueva para otro evento. La API pública puede actualizar trigger_event; vuelve a validar las suposiciones sobre el payload y el código antes de activar ese cambio.

Triggers disponibles

Cada función se asocia a uno de los siguientes 23 eventos.

Leads

Trigger	Se ejecuta cuando
`lead.created`	Un nuevo lead entra al embudo.
`lead.updated`	Se editan uno o más campos del lead, incluso cuando la API recibe un lead que ya existe y cambia algún valor. Volver a enviar los mismos datos no lo dispara.
`lead.status_changed`	Un lead pasa de un estado a otro.
`lead.assigned`	Un lead se asigna a un agente humano.
`lead.tag_added`	Se aplica una etiqueta a un lead.
`lead.unsubscribed`	Un lead se da de baja a través de WhatsApp.

Información

Trigger	Se ejecuta cuando
`information.collected`	El agente extrae un nuevo dato o variable de la conversación.
`information.updated`	Un dato recopilado previamente cambia de valor.

Conversaciones

Trigger	Se ejecuta cuando
`message.received`	Llega un mensaje entrante por un canal de mensajería compatible.
`message.sent`	Nexor registra un mensaje saliente en un canal de mensajería compatible.
`call.completed`	Una llamada de voz termina y su transcripción está lista.
`handoff.requested`	El agente escala el lead a un humano.

Conversiones

Trigger	Se ejecuta cuando
`conversion.detected`	Se registra una conversión para un lead.

Reuniones

Trigger	Se ejecuta cuando
`meeting.created`	Se agenda una reunión con un lead.
`meeting.rescheduled`	Una reunión se mueve a un nuevo horario.
`meeting.completed`	Una reunión finaliza, con transcripción opcional.
`meeting.no_show`	Un lead no asiste a una reunión agendada.

Tareas y ejecuciones del agente

Trigger	Se ejecuta cuando
`task.created`	Se crea una tarea de seguimiento programada.
`task.executed`	Se ejecuta una tarea de seguimiento programada.
`workflow.run_started`	Un lead se inscribe en un agente.
`workflow.status_entered`	Un lead entra a un estado específico de un agente.
`workflow.status_left`	Un lead sale de un estado de un agente.
`workflow.run_completed`	Una ejecución del agente llega a un estado terminal.

Usa lead.status_changed cuando necesites tanto el estado anterior como el nuevo. Usa workflow.status_entered o workflow.status_left cuando tu lógica dependa específicamente de la entrada o salida de una etapa.

Trabajar con el objeto del evento

La forma de ctx depende del trigger. Puede incluir identificadores y campos de primer nivel, además de objetos anidados como lead, estados, cambios, metadatos, participantes o el payload de una tarea. Entre los campos comunes están lead_id, client_id, workflow_id y los timestamps, pero algunos pueden ser null o no estar presentes según cómo haya ocurrido el evento. Usa la pestaña Payload para explorar el objeto de ejemplo y luego revisa Entrada (ctx) en la salida o los registros para ver el payload recibido por una ejecución específica. Protege los campos opcionales en el código de producción en vez de asumir que todos los campos del ejemplo estarán presentes. La función puede usar los siguientes valores, helpers y características del lenguaje. Los elementos integrados del entorno no requieren imports.

Valor o helper	Propósito
`ctx`	El payload completo específico del trigger.
`lead`	El objeto del lead derivado de `ctx.lead`, o un objeto vacío cuando el evento no incluye una copia del lead.
`updateLead(patch)`	Pone en cola un patch para el lead de Nexor.
`updateMetadata(patch)`	Pone en cola keys para fusionar en `lead.metadata` sin reemplazar las demás.
`env.NAME`	Lee una variable de entorno de la organización durante la ejecución.
`axios`	Hace solicitudes HTTP con `get`, `post`, `put`, `patch`, `delete`, `head` u `options`.
`fetch`	Hace solicitudes HTTP de más bajo nivel.
`console`	Captura entradas de `log`, `info`, `warn`, `error` y `debug` en la salida de la ejecución.
`helpers.uuid()`	Genera un UUID.
`helpers.now()`	Devuelve la hora actual.
`return`	Guarda un valor JSON serializable como resultado de la ejecución.

updateLead y updateMetadata cambian la copia de lead dentro del entorno aislado y guardan los efectos correspondientes. Nexor los aplica solo después de una ejecución automática exitosa. No se aplican si la función genera un error, alcanza el timeout o se ejecuta como prueba.

Enviar un evento fuera de Nexor

Este ejemplo asocia lead.status_changed con un endpoint de un CRM. Filtra por el estado qualified, crea el payload externo a partir de ctx, lo envía con un token secreto y registra la sincronización exitosa en el lead de Nexor.

export default async function onLeadStatusChanged(ctx) {
  if (ctx.to_status?.key !== "qualified") {
    return { skipped: true };
  }

  const payload = {
    type: "lead.status_changed",
    occurred_at: ctx.changed_at,
    lead_id: ctx.lead_id,
    workflow_run_id: ctx.workflow_run_id,
    status: {
      from: ctx.from_status?.key ?? null,
      to: ctx.to_status?.key ?? null,
    },
    reason: ctx.reason ?? null,
  };

  const response = await axios.post(env.CRM_EVENTS_URL, payload, {
    headers: {
      Authorization: `Bearer ${env.CRM_API_TOKEN}`,
    },
  });

  updateMetadata({
    last_crm_sync_at: helpers.now(),
  });

  console.log("CRM response:", response.status);
  return { synced: true, status: response.status };
}

Puedes usar el mismo patrón con cualquier servicio HTTP: un CRM, data warehouse, API interna, endpoint de notificaciones, plataforma de automatización u otro sistema que acepte solicitudes.

Variables de entorno

Los administradores gestionan las variables de la organización desde Integraciones → Desarrolladores → Variables de entorno. La lista del dashboard muestra los nombres, no los valores; esta pantalla no vuelve a mostrar un valor guardado. Cloud Functions y Funciones programadas comparten este registro. Lee una variable en el código como env.NAME, por ejemplo env.CRM_API_TOKEN. Una función puede leer los valores guardados durante la ejecución. Crear, reemplazar o eliminar una variable vuelve a desplegar cada Cloud Function y Función programada activa de la organización. Una función en pausa toma el cambio cuando se activa. Una organización puede guardar hasta 128 variables. Los nombres deben comenzar con una letra mayúscula y contener solo letras mayúsculas, números o guiones bajos, con un máximo de 64 caracteres. Cada valor no vacío puede contener hasta 5 KiB.

Guarda un borrador

Guardar código en el editor guarda un borrador. Los eventos que coinciden siguen ejecutando la versión publicada hasta que publicas el borrador.

El editor muestra Cambios sin publicar con la hora en que se guardó el borrador, y la lista de funciones muestra el badge Cambios sin publicar.
Cada función tiene un borrador, compartido por todas las personas que la editan, la API y Nexor AI. El último guardado lo reemplaza.
Solo el código queda en borrador. El nombre, la descripción y Activa se guardan de inmediato cuando eliges Guardar.
Guardar un código idéntico a la versión publicada no deja borrador.
Para eliminar el borrador, abre ⋯ y elige Descartar borrador. La versión publicada sigue activa.

El editor de la Cloud Function con Cambios sin publicar, el botón Historial de versiones y Guardar, Probar y Publicar cambios.

Prueba sin efectos reales

Elige Probar (⌘↵), o Probar ahora en Registros. Los cambios sin guardar se guardan primero en el borrador. Si no hay borrador, Probar ejecuta la versión publicada. En el diálogo Prueba tu borrador, edita el ctx de ejemplo o carga un lead real, y luego elige Ejecutar prueba. La prueba corre en una copia de prueba de la función:

Tu código hace	Durante una prueba
Una solicitud `GET`, `HEAD` u `OPTIONS`	Se envía de verdad, con tus headers y variables de entorno.
Cualquier otra solicitud (`POST`, `PUT`, `PATCH`, `DELETE`)	No se envía. Tu código recibe una respuesta `200` con el cuerpo `{}`. La ejecución muestra la solicitud como Se enviaría, con sus headers y su cuerpo.
`updateLead`, `updateMetadata` y otros efectos	Se muestran como (vista previa, no aplicado). Nada cambia en Nexor.
`WebSocket` o `EventSource`	Lanza un error.

Una prueba tiene los mismos límites que una ejecución real: hasta cinco minutos y 20 solicitudes salientes. Aparece en Registros con el origen Prueba, pero no cambia el conteo de ejecuciones ni la última ejecución. La prueba de un código nuevo puede tardar unos segundos más porque primero se prepara la copia de prueba.

El resultado de una prueba con una solicitud GET enviada, una solicitud POST marcada como Se enviaría y cambios en el lead marcados como vista previa, no aplicado.

Lo que una prueba no puede evitar

Un GET que cambia algo en el otro sistema, como un enlace para darse de baja o un webhook que se dispara con GET, se ejecuta de verdad durante una prueba.
Las escrituras reciben una respuesta simulada {}. El código que lee campos de esa respuesta, como un ID que espera de vuelta, puede tomar un camino distinto al de producción.
Solo las solicitudes hechas con fetch o axios aparecen como Se enviaría. Una escritura hecha con globalThis.fetch también se bloquea, pero no aparece en la lista.
Una conexión TCP directa abierta con una API de sockets no se retiene.

Publica los cambios

Elige Publicar cambios cuando el borrador esté listo. El diálogo indica qué versión será y muestra la última prueba de este borrador. Avisa si el borrador no se probó o si su última prueba falló, pero no impide publicar.

El próximo evento que coincida usa la versión nueva. Las ejecuciones que ya están en curso terminan con la anterior.
Publicar una función en pausa no la activa.
Si alguien guardó el borrador después de que abriste el diálogo, te pide revisarlo y publicar de nuevo.
Si la versión nueva no se puede desplegar, no se publica nada y tu borrador se conserva. Inténtalo de nuevo en un momento.

El diálogo Publicar cambios explica que producción ejecuta este código desde su próxima ejecución y qué versión será, con el resultado de la última prueba.

Para comprobar una escritura real, publica el código con la función en pausa, actívala y revisa sus próximas ejecuciones en Registros. El dashboard no tiene una ejecución manual real para Cloud Functions.

Restaura una versión anterior

Cada publicación crea una versión numerada. Abre Historial de versiones en el editor para ver cada versión, quién la publicó y cuándo. Publicada marca la versión activa. API pública marca las versiones publicadas con una clave de API o con Nexor AI, y Antes de las versiones marca el código que tenía la función cuando empezó el historial. Elige Ver para leer el código de una versión y luego Restaurar al borrador para copiarlo en el borrador. Restaurar nunca cambia producción: prueba el borrador y publícalo para volver atrás. Si hay un borrador abierto, Nexor pregunta antes de reemplazarlo. Restaurar la versión activa borra el borrador.

El Historial de versiones con la versión publicada y una versión anterior, cada una con quién la publicó, la fecha y Ver.

Activa una función

Cuando Guardar activa una función que tiene un borrador, Nexor pregunta primero: la función ejecuta la versión publicada, y tus cambios sin publicar no se incluyen hasta que los publiques. Si la versión publicada no se pudo desplegar, la función muestra Sin desplegar en la lista y un aviso en el editor. Cada ejecución intenta desplegarla otra vez antes de correr y se detiene si vuelve a fallar.

Revisar ejecuciones

La salida del editor y la página Registros te permiten seguir cada ejecución. Una ejecución incluye:

su origen y trigger;
el estado de éxito, error o timeout;
la duración y el timestamp;
el ctx de entrada;
la salida de consola y los errores no controlados;
vistas previas redactadas de solicitudes y respuestas HTTP, con bodies limitados a 16 KiB;
el resultado devuelto; y
los efectos sobre el lead y sus metadatos producidos por la función.

Las ejecuciones automáticas solo usan la versión publicada. Probar guarda tus cambios en el borrador antes de ejecutarse. Las ejecuciones automáticas son asíncronas y no garantizan la entrega; tampoco bloquean el evento de Nexor que las invocó. Haz que las acciones externas sean idempotentes y usa los registros para monitorear su resultado.

Usa Nexor AI, el MCP o la API

Nexor AI y los clientes MCP siguen el mismo flujo. update_cloud_function guarda los cambios de código como borrador y devuelve su draft_hash. test_cloud_function ejecuta el borrador y lista las llamadas que se enviarían; run_cloud_function ahora hace lo mismo. publish_cloud_function requiere confirm: true después de que apruebas, y el draft_hash que se probó. discard_cloud_function_draft, list_cloud_function_versions, get_cloud_function_version y restore_cloud_function_version gestionan el borrador y el historial. Con la API pública, las claves MCP necesitan workflows:read para lecturas y versiones, y workflows:write para todas las demás llamadas. Enviar code al endpoint de actualización sigue publicándolo de inmediato y registra una versión. POST /cloud-functions/{id}/run mantiene su comportamiento: ejecuta la versión publicada sin aplicar efectos, y sus solicitudes HTTP son reales.

Guardar un borrador

Cambia el código sin cambiar lo que ejecuta producción.

Probar una Cloud Function

Ejecuta el borrador con lecturas enviadas, escrituras retenidas y efectos previsualizados.

Publicar un borrador

Convierte el borrador probado en la versión publicada.

Listar versiones

Lee las versiones publicadas y restaura una en el borrador.

¿Cloud Functions o webhooks?

Usa una Cloud Function cuando el evento necesite código: filtros, transformaciones, bifurcaciones, llamadas a varios sistemas o una escritura en el lead de Nexor. Usa un webhook cuando solo necesites que Nexor entregue un evento firmado a un endpoint que ya administras. Usa una Función programada cuando el código deba ejecutarse con una programación cron y recibir una cohorte de leads, Agentes de IA activos o hosts humanos elegidos mediante una consulta. Las Cloud Functions y los webhooks usan nombres de eventos y contratos de payload diferentes. Por ejemplo, el trigger de Cloud Functions es lead.status_changed, mientras que el evento de webhook relacionado es workflow_run.status_changed. No proceses ctx como si fuera el envelope de un webhook.

Haz que las actualizaciones de leads sean idempotentes, especialmente en funciones que reaccionan a lead.updated o a cambios de estado. Evita procesar el mismo estado dos veces o volver a disparar la lógica después de tu propia actualización.

Empieza aquí

Quickstart

Referencia API

Configura y lanza

WhatsApp

Canales

Agentes

Reuniones

Integraciones

Cuenta

Bandeja de entrada

Métricas

Herramientas para desarrolladores

Referencia de soporte

Cloud Functions

Cómo funciona

Crear una función