¿OpenConnector en tu infraestructura u OOMOL alojado? Primero, pon en marcha la integración

Al conectar Google, Zoom o monday.com a una aplicación o un agente, quizá te plantees desplegar tu propia pasarela. OpenConnector es de código abierto, así que la opción está disponible desde el principio.

Una pasarela propia permite decidir dónde se guardan las credenciales, qué operaciones se autorizan y cómo se registran las llamadas. Pero, una vez arrancado el servicio, queda un trabajo fácil de subestimar: configurar la autorización de cada aplicación.

Para la mayoría de los equipos que quieren lanzar una funcionalidad pronto, recomendamos empezar con OOMOL alojado y conectar el producto mediante el SDK. Despliega OpenConnector si el servicio y las credenciales deben permanecer en tu infraestructura, o si necesitas modificar la pasarela o los conectores.

También puedes avanzar por etapas: poner en marcha la integración con el servicio alojado, preparar tus aplicaciones OAuth en paralelo y migrar cuando estés listo.

Empieza por lo que necesitas ahora

Necesidad actual	Opción recomendada
Conectar aplicaciones rápidamente y poder usar alojamiento externo	Empezar con OOMOL alojado
Compartir conexiones y centralizar el acceso de los miembros y las operaciones permitidas	Usar las funciones de equipo de OOMOL alojado
Usar aplicaciones OAuth propias que aún se están configurando o revisando	Empezar alojado y evaluar la migración cuando estén listas
Mantener credenciales, pasarela y registros de ejecución en tu infraestructura	Desplegar OpenConnector
Modificar conectores, adaptar la pasarela o controlar las conexiones de red salientes	Desplegar OpenConnector

El tamaño de la empresa puede influir. Las preguntas más directas son cuánto control necesita el equipo y cuánto mantenimiento está dispuesto a asumir.

El despliegue propio suele empezar por OAuth

Arrancar OpenConnector con Docker proporciona una pasarela de conexión. Para acceder a servicios que usan OAuth, también debes crear tu propia aplicación OAuth en la consola de desarrolladores de cada proveedor.

Hay dos credenciales distintas. El Client ID y el Client Secret identifican tu aplicación. El token de acceso, obtenido después de que un usuario autorice una cuenta, permite acceder a los recursos que ese usuario ha aprobado.

Preparas las primeras antes de conectar la cuenta. El token se obtiene durante la autorización.

Con Google, por ejemplo, debes crear un proyecto, activar las API necesarias, crear un cliente OAuth, indicar la URL de retorno y elegir los permisos solicitados. Según los permisos y el uso previsto, puede ser necesaria una verificación de la aplicación. Documentación oficial de Google OAuth

Otros servicios OAuth tienen sus propias reglas de configuración y distribución. Una integración puede ser manejable; varias implican mantener por separado la configuración de clientes, las URL de retorno, los permisos y el estado de las revisiones.

Las pruebas internas y el acceso para muchos clientes también pueden tener requisitos distintos. Algunos servicios permiten empezar con tu cuenta o con usuarios de prueba. Otros exigen aprobación del administrador o revisiones adicionales para ciertos usos. Consulta la consola y la documentación del proveedor.

OpenConnector guarda la configuración OAuth, conecta cuentas y ejecuta operaciones. Si utilizas aplicaciones OAuth propias, tu equipo sigue siendo responsable de crearlas y cumplir los requisitos de cada proveedor. Consulta la guía de configuración de aplicaciones OAuth.

Usa el alojamiento para dedicar tiempo a la integración

Si buscas lanzar una función —consultar calendarios, organizar correos o actualizar registros de un proyecto—, puedes empezar por hacer funcionar las conexiones necesarias.

En las integraciones compatibles con aplicaciones OAuth gestionadas, OOMOL reduce el trabajo de crear y mantener una aplicación para cada proveedor. Aun así, debes conectar tus cuentas y aprobar los permisos necesarios. Los servicios que usan claves API u otros métodos de autenticación también requieren su configuración correspondiente.

Una vez conectada la cuenta, OOMOL alojado se encarga de guardar las credenciales, renovar los tokens y llamar a las aplicaciones. Tu backend usa el SDK para elegir una conexión, enviar parámetros y recibir resultados. No necesitas incorporar los tokens originales del proveedor al código de negocio o a los prompts del agente. Guía del Connector alojado

Diagrama: las dos opciones de despliegue. Cambian la ubicación y las responsabilidades de gestión; el acceso a aplicaciones externas sigue dependiendo de la autorización del proveedor y de la conectividad.

El alojamiento también aporta gestión del equipo. Los administradores gestionan miembros, establecen las operaciones permitidas de cada conexión y deciden quién puede utilizarla.

Por ejemplo, una misma cuenta de correo puede tener dos conexiones. Una permite leer mensajes y se asigna a quienes necesitan consultarlos. La otra permite enviar mensajes y se reserva para quienes se encargan de la comunicación externa. Los miembros ejecutan las operaciones aprobadas sin recibir el token de acceso original del buzón. Permisos de equipos y conexiones

Estos controles permiten gestionar los accesos a medida que añades aplicaciones. El acceso a datos concretos sigue limitado por los permisos de la cuenta original y el alcance de la autorización.

Si cada usuario de tu producto necesita conectar sus propias cuentas, usa Connector for SaaS y el cliente ProjectConnector en el servicio alojado para separar las conexiones por usuario.

Elige OpenConnector para controlar el entorno de ejecución

Algunos equipos tienen requisitos claros desde el principio: proteger las credenciales con sus propias claves y almacenamiento, ejecutar la pasarela en la red corporativa y conservar los registros según reglas internas.

Esos requisitos determinan el despliegue. Con OpenConnector autogestionado, el equipo administra la pasarela, credenciales, políticas de operaciones y registros, además de bases de datos, copias de seguridad, actualizaciones y acceso a la red.

El código abierto también permite controlar la implementación. El entorno de ejecución, las definiciones de conectores, el código que ejecuta las operaciones y la consola web tienen código fuente público, igual que Connector SDK y oo CLI. Puedes partir del proyecto existente para revisar las llamadas, añadir integraciones o modificar el código. Los requisitos de autorización y las condiciones de las API de terceros siguen aplicándose por separado.

Este control conlleva mantenimiento. Alguien debe ocuparse de las claves, la protección de accesos, las actualizaciones, las copias y los incidentes. La seguridad depende de cómo se realice ese trabajo.

Elige según tu entorno:

• Docker Compose: ejecución en tus servidores o red corporativa, con gestión propia del almacenamiento y de los límites de acceso.
• Cloudflare Workers: despliegue de OpenConnector gestionado por tu equipo sobre infraestructura Cloudflare, incluidos D1 y R2, si un entorno en la nube es aceptable.
• Ejecución desde el código fuente: desarrollo de conectores, depuración o modificación de OpenConnector.

Cloudflare es una opción en la nube. Si es obligatorio ejecutar el servicio dentro de la red corporativa, elige un entorno de servidores que cumpla esa condición.

Una pasarela interna también necesita acceso saliente adecuado. Las llamadas a SaaS externos como Google o Zoom requieren llegar a sus API y endpoints de autorización. Si el entorno no tiene acceso externo, comprueba primero si el servicio dispone de una interfaz interna accesible.

Consulta la guía de despliegue propio de OpenConnector.

Empieza alojado y migra cuando estés listo

Si planeas utilizar aplicaciones OAuth propias, pero sigues configurándolas o esperando una revisión, avanza en paralelo: valida la integración con alojamiento y prepara las credenciales y el entorno para el despliegue propio.

Las dos opciones utilizan el paquete SDK @oomol-lab/connector. Incluye Connector para conexiones alojadas, ProjectConnector para usuarios finales de un producto y OpenConnector para un entorno autogestionado. Los clientes comparten tipos de operaciones y convenciones de llamada, pero difieren en autenticación, separación de cuentas y métodos disponibles. Referencia del SDK TypeScript

Puedes reutilizar los identificadores, parámetros de entrada y formas de llamada de las operaciones compatibles. Una búsqueda de correo, por ejemplo, puede conservar el nombre de la operación y la consulta, usando el cliente que conecta con tu instancia de OpenConnector.

Para preparar la migración:

1. Despliega y protege OpenConnector en el nuevo entorno y configura tus aplicaciones OAuth.
2. Establece las conexiones de las cuentas y confirma los permisos necesarios.
3. Ajusta el cliente SDK, la URL del servicio, el token del entorno de ejecución y la selección de conexiones.
4. Comprueba el soporte de las operaciones y de las funciones de equipo, usuarios de proyecto y permisos que necesita tu aplicación.
5. Valida una operación habitual antes de cambiar progresivamente las demás llamadas.

Las conexiones de cuentas y las funciones de gestión alojadas requieren atención por separado. El SDK común permite conservar llamadas y estructuras de parámetros existentes y reduce el trabajo de volver a integrar cada API.

Migrar es opcional. Sigue con el alojamiento mientras cubra tus necesidades. Asume la gestión de la pasarela cuando controlar el entorno sea un requisito concreto.

Empieza con una operación real

Si ahora no necesitas un despliegue propio, elige una función que quieras lanzar: leer el calendario de hoy, buscar correos de clientes o consultar el avance de un proyecto.

Conecta una aplicación en OOMOL Console, autoriza la cuenta y sigue la guía de integración SDK para llamar a una operación desde el backend. Comprueba que funciona y después configura miembros y permisos.

Si el despliegue propio ya es obligatorio, sigue la guía de OpenConnector y completa la configuración OAuth.

Elige el punto de partida que se ajuste a tus necesidades actuales. El alojamiento te ayuda a poner en marcha la integración; OpenConnector de código abierto permite controlar el código, las credenciales y el entorno cuando lo necesitas.