Se recurre a n8n cuando el CRM tiene que hablar con algo que desconoce: una base de almacén, un servicio interno, una API ajena. Y la primera hora se va en una pregunta que los tutoriales esquivan: no hay un nodo «Bitrix24» listo para arrastrar al lienzo. La conexión existe y no es difícil, pero se monta con bloques genéricos, y luego se rompe siempre por los mismos sitios. Aquí está la forma que funciona para unir Bitrix24 (Alaio) y n8n en las dos direcciones.

¿Existe un nodo de Bitrix24 en n8n?

Oficial, no. La propia página de Bitrix24 en n8n remite al nodo HTTP Request con autenticación genérica, que es la respuesta honesta: la API REST la llama usted. Hay paquetes de la comunidad y algunos cubren bien entidades de CRM, tareas y telefonía, pero los mantienen terceros, van por detrás de los cambios de la API y, en instancias gestionadas, instalarlos es una decisión de política y no un clic. Para un escenario de tres o cuatro métodos, el nodo HTTP Request cuesta menos que auditar código ajeno: la API es JSON simple sobre HTTPS y un solo nodo sirve para cualquier método.

¿Cómo escribe n8n datos en Bitrix24?

Con un webhook entrante. En el portal se crea desde el apartado para desarrolladores: marca los permisos que necesita y obtiene una dirección del tipo https://<portal>/rest/<id-de-usuario>/<token>/<metodo>.json. La autorización va dentro de la propia dirección, así que el nodo HTTP Request no necesita nada más que ese enlace y cuidado al manejarlo. El nombre del método y los parámetros viajan tal como los describe la documentación: crm.item.add, crm.item.update, tasks.task.add.

Dos propiedades de esa dirección deciden casi todo lo que viene después. El webhook trabaja con los permisos del empleado que lo creó: un escenario que no puede ver un embudo falla por permisos con un token perfectamente válido, así que cree los webhooks bajo una cuenta de servicio y no bajo quien estuviera delante del ordenador ese día. Y el token no se renueva solo: vive hasta que alguien lo borra o desactiva a ese empleado, de ahí su comodidad y el precio de una fuga. La mecánica de ambas direcciones está en la guía de webhooks.

¿Cómo lanzo un escenario de n8n desde Bitrix24?

Hay dos caminos y se comportan distinto. El webhook saliente del portal se suscribe a eventos —negocio modificado, lead creado— y llama a la dirección de su nodo Webhook. Se dispara con cada evento que encaje, venga el cambio de una persona, de una importación o de otra integración. El contenido llega como datos de formulario y no como JSON, por eso en la primera ejecución el nodo muestra campos sueltos en lugar de un cuerpo.

El segundo camino llama a n8n desde el propio proceso. La regla Solicitud HTTP GET/POST golpea la dirección del nodo Webhook exactamente en el punto que usted elija y envía solo los datos que decida enviar. Construir JSON a partir de campos arma el cuerpo con valores del proceso sin escapar comillas a mano, y Extraer valor de JSON por ruta devuelve al proceso la respuesta de n8n — el tratamiento de respuestas se detalla en el artículo sobre JSON en los procesos de negocio. Donde la entrega no puede perderse —un pedido que entra en producción, un documento que va a firma— ponga Webhook tolerante a fallos: reintenta con su propio calendario e informa de cuántos intentos hicieron falta, en vez de callarse tras el primer fallo.

¿Qué mitad del escenario conviene dejar en el portal?

La mitad que nunca sale de él. Cambiar de etapa, rellenar un campo, crear una tarea, bifurcar por una condición: llevar eso a un escenario externo compra un viaje de ida y vuelta por la red, un segundo sitio donde depurar y una cuota que vigilar, y nada más. El reparto razonable es sencillo: n8n se ocupa de los sistemas de fuera, el portal de sus propios registros, y entre ambos una llamada. El coste de esa decisión está desglosado en la comparación entre conectores y automatización dentro del portal; la parte interna es la configuración de reglas de automatización de siempre.

¿Por qué el escenario se queda mudo?

Empiece por el lado de n8n: el nodo Webhook tiene dos direcciones, una de prueba y una de producción, y la de producción solo responde con el escenario activo, así que una conexión construida y verificada en modo prueba enmudece justo cuando dejan de mirarla. Siga por el lado del portal: un webhook saliente colgado del evento equivocado, o de un tipo de entidad que la regla nunca toca, no genera ninguna petición; una lista de ejecuciones vacía en n8n es un problema de suscripción, no de red.

Si las peticiones llegan y vuelven con error, lea el texto en lugar de reintentar: permisos insuficientes del webhook, un código de campo mal escrito y un límite superado se parecen todos a «no funciona», pero se arreglan de forma distinta. El límite merece un hueco aparte en la cabeza: el portal admite un par de llamadas por segundo, y un bucle sobre unos cientos de registros sin pausas se choca con él por sí solo. Y cuando lo que no arrancó fue la regla con la que debía empezar todo, el repaso está en por qué no funcionan las reglas de automatización.

Qué hacer a continuación

Descomponga su escenario en dos listas: pasos que tocan sistemas externos y pasos que solo tocan registros del portal. La segunda lista se muda hacia dentro; lo habitual es que después quede un webhook por dirección, y eso se mantiene vivo con mucho menos esfuerzo. Los bloques para la parte del portal están en el catálogo de reglas, y si falta el que necesita, describa la tarea: Roboteka crea gratis las reglas que faltan y las publica en la biblioteca común.