A UnifAPI agora vem no OpenConnector open source da OOMOL: conecte uma vez com uma key do workspace, compartilhe com o time e some escritas via OAuth.

Em resumo: a UnifAPI agora é um provider nativo no OpenConnector open source da OOMOL, espelhando nosso catálogo completo de dados públicos — todas as 16 plataformas — como Actions tipadas e chamáveis. Um admin conecta a UnifAPI uma vez com uma API key de workspace; a empresa inteira lê dados públicos ao vivo através dessa conexão compartilhada, ao lado das tools de escrita via OAuth que a OOMOL já intermedia. O offboarding é um clique na OOMOL — nada para rotacionar do lado da UnifAPI.

As integrações de agents sempre se dividiram em duas metades. Uma metade é privada: o Gmail, o Notion, o Linear e o Slack do próprio usuário — dados que só aquele usuário pode autorizar, geralmente via OAuth, geralmente com acesso de escrita. A outra metade é pública: posts, perfis, vídeos, threads, rankings, SERPs — evidência que qualquer pessoa com um navegador poderia ler, e que é todo o produto da UnifAPI.

Até agora, os times conectavam essas metades separadamente: uma plataforma de conectores para as tools OAuth, uma chave direta ou uma conexão MCP para os dados públicos, e duas respostas diferentes para "quem tem acesso, e como revogamos?". Hoje estamos fechando essa lacuna. A UnifAPI é um provider nativo no OpenConnector da OOMOL, então a metade de dados públicos e a metade de OAuth vivem atrás de um único gateway, um único catálogo e uma única superfície de gestão de times.

Quem é a OOMOL

A OOMOL constrói infraestrutura de integração para agents e para os times que os operam. Se você a comparou com o Composio, está na vizinhança certa — um gateway de conectores que intermedia a autenticação entre agents e serviços de terceiros —, mas a OOMOL chegou lá por um caminho incomum, e o desvio aparece no produto.

A empresa apareceu pela primeira vez no Hacker News em meados de 2025 com o OOMOL Studio, apresentado como um motor de automação de workflows local-first, code-first. Onde o Zapier e o n8n oferecem um canvas de nós pré-construídos e uma caixinha de expressões apertada para todo o resto, o Studio é construído sobre uma base do VS Code: cada block em um workflow é código real em Python ou Node.js, rodando em um container para que bibliotecas de terceiros se comportem de forma idêntica em qualquer máquina. Sob o canvas fica o OOCANA, um motor de workflows implementado em Rust que agenda fluxos e blocks declarados em arquivos YAML simples. Blocks e templates de workflow são compartilháveis, então os times acumulam uma biblioteca de peças funcionais em vez de capturas de tela de grafos de nós.

Ao redor desse núcleo, o ecossistema cresceu do jeito que infraestrutura de agents costuma crescer: o oo CLI, um relay de linha de comando que permite que agents pesquisem, inspecionem e executem tools publicadas; o OOMOL Cloud, o runtime hospedado para workflows que precisam de entrega contínua e configuração gerenciada; e o Wanta, um app de desktop em que você conecta contas uma vez e trabalha com todas elas em linguagem natural.

O tecido conjuntivo de tudo isso é o OpenConnector — a peça na qual a UnifAPI agora se encaixa.

Por dentro do OpenConnector

O OpenConnector é um gateway de conectores open source sob licença Apache 2.0. Sua tagline é "Connect Once. Use Everywhere", e ela é literal: você conecta uma conta uma vez, e um catálogo compartilhado com mais de 1.000 providers e mais de 9.400 Actions pré-construídas fica chamável a partir de qualquer superfície que seu time use — um SDK TypeScript a partir do código da aplicação, o oo CLI como relay local de agent, MCP a partir de hosts de agent, HTTP/OpenAPI puro a partir de clientes customizados e um Web Console para administração e depuração.

Duas decisões de design importam para o que vem a seguir.

Primeiro, cada Action é um contrato inspecionável: esquemas de request/response, escopos exigidos e o próprio código-fonte do executor são todos legíveis. Você pode auditar o que uma Action faz antes que um agent sequer a chame — a mesma postura de "leia o contrato, não o marketing" que adotamos com o OpenAPI.

Segundo, as credenciais são arquiteturalmente separadas dos agents que as usam. API keys e tokens OAuth ficam selados em repouso (AES-256-GCM), os agents chamam através de fluxos do lado do servidor e nunca veem um segredo bruto, políticas de allow/block delimitam quais Actions cada consumidor pode invocar, e cada chamada grava um registro de auditoria — ator, escopo, timestamp, resultado — com saídas censuradas nos logs de execução. Um agent que sai dos trilhos pode ser cortado na camada de políticas; ele nunca teve a chave em mãos, para começo de conversa.

Essa é a maquinaria. Eis por que a UnifAPI faz sentido dentro dela.

Olhos encontram mãos

O posicionamento da UnifAPI é consistente desde o primeiro dia: eyes, not hands — olhos, não mãos. Nós lemos dados públicos — TikTok, LinkedIn, Instagram, YouTube, Twitter/X, Threads, Reddit, Hacker News, notícias, sinais de SEO e GEO, mapas e listagens locais —, normalizamos tudo em um único envelope e nunca guardamos suas credenciais de publicação. Pesquisa, monitoramento, auditorias, precificação: leituras.

O catálogo da OOMOL é mais forte na metade oposta. A maioria daqueles mais de 1.000 providers é OAuth para SaaS privado — as mãos. Suas conexões permitem que um agent atue dentro de contas que o usuário realmente possui: enviar a mensagem no Slack, atualizar a página do Notion, abrir o ticket no Linear, redigir o e-mail.

Isso fez da lacuna de cada lado o produto do outro. Um gateway de conectores cheio de tools de escrita ainda precisa de evidência sobre a qual agir, e construir uma camada de dados públicos ao vivo, normalizada e juridicamente cuidadosa é um produto em tempo integral, não uma feature. Uma camada de dados públicos ainda precisa de um lugar onde os achados possam aterrissar, e intermediar OAuth para centenas de apps SaaS é, igualmente, o trabalho inteiro de alguém. Coloque os dois atrás do mesmo gateway e o ciclo se fecha sem que nenhum dos lados comprometa seu modelo:

"Find what TikTok creators said about our launch this week" → UnifAPI, leituras públicas.

"Post the digest to #marketing and file follow-ups in Linear" → conexões OAuth da OOMOL, escritas privadas.

Seu assistente chama os dois através de um único catálogo. A UnifAPI continua sem jamais tocar suas contas privadas — essa fronteira é estrutural, não incidental — e a OOMOL não precisa manter uma camada de dados públicos, porque as leituras vêm de um provider cujo único trabalho é mantê-las ao vivo, normalizadas e precificadas por registro.

Uma chave, a empresa inteira

A parte que mais nos anima é o que a camada de times da OOMOL faz com o onboarding da UnifAPI.

Uma API key da UnifAPI pertence a um Workspace e gasta os credits desse workspace. Antes desta parceria, compartilhá-la em uma empresa significava o que compartilhar chaves sempre significa: colar em um cofre ou em um arquivo env, torcer para que nunca vaze em um laptop, um notebook de código ou um repositório e rotacionar toda vez que alguém sai — e então caçar cada lugar onde a chave antiga ficou em cache.

Através da OOMOL, funciona do jeito que credenciais de time deveriam funcionar:

Um admin cria uma chave no console da UnifAPI e a salva como uma conexão UnifAPI na OOMOL — uma vez. Todo mundo no time chama a UnifAPI através dessa conexão compartilhada, a partir de workflows do Studio, de agents por trás do oo CLI ou do MCP, ou de código de backend via SDK. A chave bruta nunca circula; os colegas referenciam a conexão pelo nome enquanto o segredo permanece selado dentro do gateway. Políticas de allow/block decidem quais Actions cada consumidor pode chamar — o agent de pesquisa do analista pode ler TikTok e Reddit, o experimento do estagiário não pode tocar nos endpoints de SEO — e a trilha de auditoria mostra qual sistema usou qual conexão para quê.

E quando alguém sai, você remove o acesso dessa pessoa na OOMOL. Só isso. Nenhuma rotação de chave, nenhum redeploy, nenhuma mudança do lado da UnifAPI — a chave do workspace nunca esteve nas mãos dela. O uso continua fluindo para o mesmo workspace da UnifAPI, então a cobrança continua sendo um saldo, um extrato, por registro.

Cada plataforma da UnifAPI, como Actions tipadas

Isto não é uma troca de logotipo nem um wrapper fino em torno de três endpoints. O provider da UnifAPI no OpenConnector espelha nosso catálogo plataforma por plataforma: TikTok, Twitter/X, Instagram, YouTube, LinkedIn, Threads, Reddit, Hacker News, notícias, SEO, GEO, mapas, dados locais, hotéis, eventos e fetch com navegador renderizado — as mesmas 16 plataformas e 220 operações por trás de unifapi.com/apis, cada uma gerada como uma Action tipada com esquemas de entrada e saída que um agent pode inspecionar antes de chamar.

Como as Actions são geradas a partir de definições de operação tipadas em vez de escritas à mão, o provider acompanha nossa superfície OpenAPI: quando o catálogo cresce, o conector cresce junto. E a cobrança não muda de forma no caminho — chamadas através da OOMOL gastam os credits do seu workspace da UnifAPI ao mesmo preço por registro do uso direto via HTTP ou MCP, com os mesmos metadados de billing em cada resposta.

Open source, self-hostable

O OpenConnector é Apache 2.0, e o provider da UnifAPI é distribuído no catálogo público — você mesmo pode ler o código-fonte do provider: autenticação por API key, enviada como um header Bearer padrão, com actions geradas por plataforma.

Isso importa porque a história de times acima não exige confiar em uma caixa-preta hospedada. Você pode rodar o gateway inteiro em infraestrutura que você controla — localmente via Docker ou Node.js, no Fly.io com SQLite persistente, ou no Cloudflare Workers com D1 e R2 — e obter o catálogo de providers e os contratos de Actions idênticos. O runtime hospedado da OOMOL é o caminho zero-ops com a mesma interface, então começar hospedado e migrar para self-hosted depois (ou o inverso) não muda seu código de integração.

Para times cuja revisão de segurança hesitaria em rotear credenciais por um SaaS de terceiros, essa é a diferença entre "interessante" e "aprovado": o armazenamento de credenciais, o motor de políticas e o log de auditoria podem todos viver dentro do seu próprio perímetro.

Conectando a UnifAPI através da OOMOL

A configuração é deliberadamente sem graça:

Entre no console da UnifAPI e crie uma API key de workspace (ela é exibida uma única vez, com o prefixo unif_).
Na OOMOL, adicione uma conexão UnifAPI e cole a chave. O OpenConnector cuida do header Authorization: Bearer a partir daí.
Chame as operações da UnifAPI de onde quer que seu time trabalhe — workflows do Studio, o oo CLI, assistentes conectados via MCP ou o SDK a partir do código de backend.

Se você é um operador individual rodando Skills no Claude ou no Codex, o caminho direto em unifapi.com/mcp continua sendo a configuração de três minutos. A OOMOL é o caminho que transforma a UnifAPI em um utilitário de time: conexão compartilhada, políticas com escopo, trilha de auditoria, offboarding em um clique.

Três ciclos que isso fecha

Alguns workflows que antes exigiam dois projetos de integração e agora exigem um único gateway:

Social listening de ponta a ponta. Um workflow lê menções de marca no Reddit, no TikTok e no Twitter/X através da UnifAPI, pontua as menções em um block de Python e publica um resumo matinal no Slack do time através de uma conexão OAuth — leituras públicas, escritas privadas, um catálogo, uma trilha de auditoria.

Marketing de influência com trilha documentada. Um workflow monta uma shortlist de criadores e precifica KOLs a partir de dados públicos de engajamento, e então grava a shortlist — com a evidência pública citada — no workspace do Notion do time para revisão. Quando o financeiro pergunta de onde veio um número, o log de execução responde.

Inteligência competitiva que abre os próprios tickets. Um workflow agendado observa lançamentos, threads e rankings públicos dos concorrentes e transforma qualquer coisa acionável em tickets no tracker do time, cada um com link de volta para a fonte pública.

Em todos os casos, a fronteira permanece limpa: a UnifAPI fornece evidência pública citável; as contas do próprio usuário, autorizadas através da OOMOL, executam as ações.

O quadro maior

Os agents deixaram de ser uma ferramenta solo em algum momento do ano passado. No instante em que um workflow é compartilhado — um resumo do time no Slack, um pipeline de pesquisa da empresa, uma auditoria agendada —, as perguntas mudam de "qual modelo?" para "quem pode chamar o quê, com as credenciais de quem, e o que acontece quando essa pessoa sai?". Essas são perguntas de gateway, e é por isso que os gateways de conectores se tornaram uma camada própria da stack de agents.

Nossa resposta tem duas partes. Para a metade de dados públicos, a UnifAPI continua sendo o que é: uma chave, um envelope, preço por registro, somente leitura por design. Para a metade de times, preferimos integrar com um gateway aberto e inspecionável a construir uma cópia-sombra de um. O OpenConnector da OOMOL é exatamente isso — open source, self-hostable, com um modelo de segurança que podemos apontar para nossos próprios clientes.

Conecte uma vez. A empresa inteira lê a web pública.

O que ler a seguir

UnifAPI vs Composio - o enquadramento das duas metades sobre o qual esta parceria foi construída.

Conecte a UnifAPI ao Claude via MCP - o caminho MCP direto para operadores individuais.

Stack mínima viável de agents - onde um gateway de conectores e uma camada de dados públicos se encaixam em uma mesma arquitetura.