UnifAPI se asocia con OOMOL: las lecturas de datos públicos se unen a las escrituras OAuth

En resumen: UnifAPI ya es un provider nativo en OpenConnector, el proyecto open source de OOMOL, replicando nuestro catálogo completo de datos públicos — las 16 plataformas — como Actions tipadas e invocables. Un administrador conecta UnifAPI una sola vez con una API key de Workspace; toda la empresa lee datos públicos en vivo a través de esa conexión compartida, junto a las herramientas de escritura OAuth que OOMOL ya gestiona. Dar de baja a alguien es un clic en OOMOL — no hay nada que rotar en el lado de UnifAPI.

Las integraciones de agentes siempre se han dividido en dos mitades. Una mitad es privada: el Gmail, Notion, Linear o Slack propios del usuario — datos que solo ese usuario puede autorizar, normalmente vía OAuth, normalmente con acceso de escritura. La otra mitad es pública: publicaciones, perfiles, vídeos, hilos, rankings, SERPs — evidencia que cualquiera con un navegador podría leer, y que es el producto entero de UnifAPI.

Hasta ahora, los equipos cableaban esas mitades por separado: una plataforma de conectores para las herramientas OAuth, una clave directa o una conexión MCP para los datos públicos, y dos respuestas distintas a "¿quién tiene acceso y cómo lo revocamos?". Hoy cerramos esa brecha. UnifAPI es un provider integrado en OpenConnector, de OOMOL, de modo que la mitad de datos públicos y la mitad OAuth viven detrás de un mismo gateway, un mismo catálogo y una misma superficie de gestión de equipo.

Quién es OOMOL

OOMOL construye infraestructura de integración para agentes y para los equipos que los operan. Si lo has comparado con Composio, vas por el buen camino — un gateway de conectores que gestiona la autenticación entre agentes y servicios de terceros —, pero OOMOL llegó ahí desde una dirección inusual, y ese desvío se nota en el producto.

La empresa apareció por primera vez en Hacker News a mediados de 2025 con OOMOL Studio, presentado como un motor de automatización de flujos de trabajo local-first, code-first (primero local, primero código). Donde Zapier y n8n te dan un lienzo de nodos prefabricados y una estrecha caja de expresiones para todo lo demás, Studio está construido sobre una base de VS Code: cada bloque de un flujo de trabajo es Python o Node.js real, ejecutándose en un contenedor para que las bibliotecas de terceros se comporten igual en cualquier máquina. Bajo el lienzo está OOCANA, un motor de flujos de trabajo implementado en Rust que orquesta flujos y Blocks declarados en simples archivos YAML. Los Blocks y las plantillas de flujos de trabajo se pueden compartir, así que los equipos acumulan una biblioteca de piezas que funcionan en lugar de capturas de pantalla de grafos de nodos.

Alrededor de ese núcleo, el ecosistema creció como suele crecer la infraestructura de agentes: oo CLI, un relé de línea de comandos que permite a los agentes buscar, inspeccionar y ejecutar herramientas publicadas; OOMOL Cloud, el runtime alojado para los flujos de trabajo que necesitan entrega continua y configuración gestionada; y Wanta, una aplicación de escritorio donde conectas cuentas una sola vez y trabajas sobre todas ellas en lenguaje natural.

El tejido conectivo de todo ello es OpenConnector — la pieza a la que UnifAPI se enchufa ahora.

Dentro de OpenConnector

OpenConnector es un gateway de conectores open source con licencia Apache 2.0. Su lema es "Connect Once. Use Everywhere" (conecta una vez, úsalo en todas partes), y lo dice literalmente: conectas una cuenta una sola vez, y un catálogo compartido de más de 1.000 providers y más de 9.400 Actions predefinidas queda invocable desde cualquier superficie que use tu equipo — un SDK de TypeScript desde el código de la aplicación, la oo CLI como relé local de agentes, MCP desde los hosts de agentes, HTTP/OpenAPI plano desde clientes propios y una Web Console para administración y depuración.

Dos decisiones de diseño importan para lo que sigue.

Primera: cada Action es un contrato inspeccionable — los esquemas de petición/respuesta, los scopes requeridos y el propio código fuente del ejecutor son legibles. Puedes auditar lo que hace una Action antes de que un agente la llame jamás — la misma postura de "lee el contrato, no el marketing" que nosotros adoptamos con OpenAPI.

Segunda: las credenciales están separadas arquitectónicamente de los agentes que las usan. Las API keys y los tokens OAuth se sellan en reposo (AES-256-GCM), los agentes llaman a través de flujos del lado del servidor y nunca ven un secreto en bruto, las políticas de permitir/bloquear acotan qué Actions puede invocar cada consumidor, y cada llamada escribe un registro de auditoría — actor, scope, marca de tiempo, resultado — con salidas censuradas en los registros de ejecución. Un agente que se descontrola puede cortarse en la capa de políticas; nunca tuvo la clave en su poder.

Esa es la maquinaria. Aquí está el porqué de que UnifAPI encaje dentro de ella.

Los ojos se encuentran con las manos

El posicionamiento de UnifAPI ha sido consistente desde el primer día: eyes, not hands (ojos, no manos). Leemos datos públicos — TikTok, LinkedIn, Instagram, YouTube, Twitter/X, Threads, Reddit, Hacker News, noticias, señales SEO y GEO, mapas y fichas locales —, los normalizamos en una única envoltura y nunca guardamos tus credenciales de publicación. Investigación, monitorización, auditorías, tarifas: lecturas.

El catálogo de OOMOL es más fuerte en la mitad opuesta. La mayoría de esos más de 1.000 providers son OAuth hacia SaaS privado — las manos. Sus conexiones permiten a un agente actuar dentro de las cuentas que el usuario realmente posee: enviar el mensaje de Slack, actualizar la página de Notion, crear el ticket de Linear, redactar el correo.

Eso convertía la carencia de cada lado en el producto del otro. Un gateway de conectores lleno de herramientas de escritura sigue necesitando evidencia sobre la que actuar, y construir una capa de datos públicos en vivo, normalizada y legalmente cuidadosa es un producto a tiempo completo, no una funcionalidad. Una capa de datos públicos sigue necesitando un lugar donde aterricen los hallazgos, y gestionar OAuth hacia cientos de aplicaciones SaaS es, igualmente, el trabajo entero de alguien. Pon ambas cosas detrás del mismo gateway y el bucle se cierra sin que ninguna de las partes comprometa su modelo:

"Encuentra qué dijeron los creadores de TikTok sobre nuestro lanzamiento esta semana" → UnifAPI, lecturas públicas.

"Publica el resumen en #marketing y crea los seguimientos en Linear" → las conexiones OAuth de OOMOL, escrituras privadas.

Tu asistente llama a ambos a través de un solo catálogo. UnifAPI sigue sin tocar jamás tus cuentas privadas — esa frontera es estructural, no accidental — y OOMOL no tiene que mantener una capa de datos públicos, porque las lecturas vienen de un provider cuyo único trabajo es mantenerlas en vivo, normalizadas y con precio por registro.

Una clave, toda la empresa

La parte que más nos entusiasma es lo que la capa de equipos de OOMOL hace con el onboarding de UnifAPI.

Una API key de UnifAPI pertenece a un Workspace y gasta los credits de ese Workspace. Antes de esta asociación, compartirla en toda una empresa significaba lo que compartir claves siempre significa: pegarla en un gestor de secretos o en un archivo env, esperar que nunca se filtre a un portátil, a un notebook o a un repositorio, y rotarla cada vez que alguien se va — para luego perseguir cada lugar donde la clave antigua quedó cacheada.

A través de OOMOL funciona como deberían funcionar las credenciales de equipo:

Un administrador crea una clave en la consola de UnifAPI y la guarda como conexión de UnifAPI en OOMOL — una sola vez. Todo el equipo llama a UnifAPI a través de esa conexión compartida, desde flujos de trabajo de Studio, agentes detrás de la oo CLI o de MCP, o código de backend sobre el SDK. La clave en bruto nunca circula; los compañeros referencian la conexión por su nombre mientras el secreto permanece sellado dentro del gateway. Las políticas de permitir/bloquear deciden qué Actions puede llamar cada consumidor — el agente de investigación del analista puede leer TikTok y Reddit, el experimento del becario no puede tocar los endpoints de SEO — y el registro de auditoría muestra qué sistema usó qué conexión y para qué.

Y cuando alguien se va, le quitas el acceso en OOMOL. Eso es todo. Sin rotación de claves, sin redespliegues, sin ningún cambio en el lado de UnifAPI — la clave del Workspace nunca estuvo en sus manos. El uso sigue fluyendo hacia el mismo Workspace de UnifAPI, así que la facturación se mantiene en un solo saldo, un solo libro de cuentas, por registro.

Cada plataforma de UnifAPI, como Actions tipadas

Esto no es un intercambio de logos ni una envoltura fina alrededor de tres endpoints. El provider de UnifAPI en OpenConnector replica nuestro catálogo plataforma a plataforma: TikTok, Twitter/X, Instagram, YouTube, LinkedIn, Threads, Reddit, Hacker News, noticias, SEO, GEO, mapas, local, hoteles, eventos y obtención con navegador renderizado — las mismas 16 plataformas y 220 operaciones que hay detrás de unifapi.com/apis, cada una generada como una Action tipada con esquemas de entrada y salida que un agente puede inspeccionar antes de llamar.

Como las Actions se generan a partir de definiciones de operación tipadas en lugar de escribirse a mano, el provider sigue el rastro de nuestra superficie OpenAPI: cuando el catálogo crece, el conector crece con él. Y la facturación no cambia de forma por el camino — las llamadas a través de OOMOL gastan los credits de tu Workspace de UnifAPI al mismo precio por registro que el uso directo por HTTP o MCP, con los mismos metadatos billing en cada respuesta.

Open source y autoalojable

OpenConnector es Apache 2.0, y el provider de UnifAPI se distribuye en el catálogo público — puedes leer el código fuente del provider tú mismo: autenticación por API key, enviada como una cabecera Bearer estándar, con Actions generadas por plataforma.

Eso importa porque la historia de equipo de arriba no exige confiar en una caja negra alojada. Puedes ejecutar el gateway completo en infraestructura que tú controlas — localmente vía Docker o Node.js, en Fly.io con SQLite persistente, o en Cloudflare Workers con D1 y R2 — y obtener el mismo catálogo de providers y los mismos contratos de Actions. El runtime alojado de OOMOL es la vía sin operaciones con la misma interfaz, así que empezar alojado y pasar a autoalojado más tarde (o al revés) no cambia tu código de integración.

Para los equipos cuya revisión de seguridad se resistiría a enrutar credenciales a través de un SaaS de terceros, esta es la diferencia entre "interesante" y "aprobado": el almacén de credenciales, el motor de políticas y el registro de auditoría pueden vivir todos dentro de tu propio perímetro.

Conectar UnifAPI a través de OOMOL

La configuración es deliberadamente aburrida:

1. Inicia sesión en la consola de UnifAPI y crea una API key de Workspace (se muestra una sola vez, con el prefijo unif_).
2. En OOMOL, añade una conexión de UnifAPI y pega la clave. OpenConnector se encarga de la cabecera Authorization: Bearer a partir de ahí.
3. Llama a las operaciones de UnifAPI desde donde trabaje tu equipo — flujos de trabajo de Studio, la oo CLI, asistentes conectados por MCP o el SDK desde código de backend.

Si eres un operador individual que ejecuta Skills en Claude o Codex, la ruta directa en unifapi.com/mcp sigue siendo la configuración de tres minutos. OOMOL es la ruta que convierte a UnifAPI en una utilidad de equipo: conexión compartida, políticas acotadas, registro de auditoría, baja con un clic.

Tres bucles que esto cierra

Algunos flujos de trabajo que antes exigían dos proyectos de integración y ahora requieren un solo gateway:

Escucha social, de principio a fin. Un flujo de trabajo lee menciones de marca en Reddit, TikTok y Twitter/X a través de UnifAPI, las puntúa en un bloque de Python y publica un resumen matinal en el Slack del equipo mediante una conexión OAuth — lecturas públicas, escrituras privadas, un solo catálogo, un solo registro de auditoría.

Marketing de influencers con rastro documental. Un flujo de trabajo preselecciona creadores y fija tarifas de KOL a partir de datos públicos de interacción, y luego escribe la lista corta — con la evidencia pública citada — en el espacio de trabajo de Notion del equipo para su revisión. Cuando finanzas pregunta de dónde salió una cifra, el registro de ejecución responde.

Inteligencia competitiva que crea sus propios tickets. Un flujo de trabajo programado vigila los lanzamientos, los hilos y los rankings públicos de la competencia, y convierte cualquier cosa accionable en tickets en el gestor del equipo, cada uno enlazando de vuelta a la fuente pública.

En todos los casos la frontera se mantiene limpia: UnifAPI aporta evidencia pública citable; las cuentas propias del usuario, autorizadas a través de OOMOL, ejecutan las acciones.

El panorama general

Los agentes dejaron de ser una herramienta individual en algún momento del año pasado. En cuanto un flujo de trabajo se comparte — un resumen de Slack del equipo, un pipeline de investigación de la empresa, una auditoría programada —, las preguntas cambian de "¿qué modelo?" a "¿quién puede llamar a qué, con las credenciales de quién, y qué pasa cuando se va?". Esas son preguntas de gateway, y son la razón de que los gateways de conectores se hayan convertido en una capa propia del stack de agentes.

Nuestra respuesta tiene dos partes. Para la mitad de datos públicos, UnifAPI sigue siendo lo que es: una clave, una envoltura, precio por registro, solo lectura por diseño. Para la mitad de equipo, preferimos integrarnos con un gateway abierto e inspeccionable antes que construir una copia en la sombra de uno. OpenConnector, de OOMOL, es exactamente eso — open source, autoalojable, con un modelo de seguridad al que podemos remitir a nuestros propios clientes.

Conecta una vez. Toda la empresa lee la web pública.

Qué leer a continuación

UnifAPI vs Composio - el marco de las dos mitades sobre el que se construye esta asociación.

Conecta UnifAPI a Claude vía MCP - la ruta directa por MCP para operadores individuales.

Stack mínimo viable de agentes - dónde encajan un gateway de conectores y una capa de datos públicos en una misma arquitectura.