Conexões e APIs: o cadastro compartilhado

A aba Conexões e APIs aparece dentro de SocialFlow, Studio, Bridge e Lead Conversions. É a mesma tabela nos quatro: cadastrar em um faz aparecer nos outros.

Cada conexão guarda nome, projeto, endereço, tipo de autenticação e credencial. Os blocos de fluxo escolhem a conexão pelo nome. Trocar o token do ERP é mexer em um lugar só.

A chave nunca volta para a tela. Ela é gravada criptografada; a tela mostra "chave guardada" e um campo para substituir.

Modelos prontos

Também é possível importar uma coleção do Postman (v2.1) ou um arquivo Swagger/OpenAPI: as chamadas viram uma lista pronta para usar nos blocos. O token não é importado de propósito — ele é colado depois, para não ficar registrado no arquivo de coleção.

---

Liberar o acesso ao banco em outra VPS

O caso comum tem o Talk numa VPS, o painel de vendas em outra e um CRM antigo numa terceira. A conexão parte do Talk e chega ao banco de origem, que por padrão não aceita conexão de fora. São quatro camadas para abrir, e esquecer uma delas é a causa de quase toda falha.

Passo 0: o IP a liberar

Todas as camadas abaixo liberam um endereço só — o IP de saída do Talk:

IP_DO_TALK

Esse é o IP mesmo com o domínio atrás do Cloudflare. Quando a conexão parte do Talk em direção ao banco do cliente, ela sai direto do servidor: o Cloudflare fica no caminho de quem *chega* ao Talk, não de quem o Talk *procura*. Ligar ou desligar a nuvem laranja não muda o endereço a liberar.

Por isso, não descubra o IP por dig ou nslookup no domínio: com a nuvem laranja ligada, a consulta devolve endereços do Cloudflare, e liberar aqueles não faz a conexão funcionar. Se precisar confirmar, rode no próprio servidor do Talk:

curl -s https://ifconfig.me

Nos exemplos abaixo o endereço aparece como IP_DO_TALK.

Postgres

1. Criar os usuários. Conecte como superusuário no banco de origem:

-- leitor: só consulta
CREATE USER leitor WITH PASSWORD 'senha-longa-aqui';
GRANT CONNECT ON DATABASE erp TO leitor;
GRANT USAGE ON SCHEMA public TO leitor;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO leitor;

-- tabelas criadas depois também entram
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO leitor;

2. Aceitar conexão de fora. No postgresql.conf:

listen_addresses = '*'

3. Autorizar o IP. No pg_hba.conf, acrescente uma linha — e coloque antes das regras genéricas:

# TIPO    BANCO  USUÁRIO  ORIGEM            MÉTODO
hostssl   erp    leitor   IP_DO_TALK/32     scram-sha-256

Use hostssl, não host: assim a senha não trafega em claro. Se o Postgres ainda não tem certificado, host funciona, mas trate como solução temporária.

4. Recarregar e conferir que subiu:

sudo systemctl reload postgresql
# ou, em container:
docker exec -it <container_do_postgres> psql -U postgres -c 'SELECT pg_reload_conf();'

5. Firewall. Libere a porta apenas para o IP do Talk:

sudo ufw allow from IP_DO_TALK to any port 5432 proto tcp
sudo ufw status numbered      # confira que não existe um "5432 ALLOW Anywhere"

6. Docker. Se o banco roda em container, a porta precisa estar publicada no host. No docker-compose.yml:

services:
  postgres:
    ports:
      - "5432:5432"

No Portainer: Containers › o container › Duplicate/Edit › Port mapping, host 5432 para container 5432.

MySQL e MariaDB

1. Criar os usuários, já amarrados ao IP de origem:

CREATE USER 'leitor'@'IP_DO_TALK' IDENTIFIED BY 'senha-longa-aqui';
GRANT SELECT ON erp.* TO 'leitor'@'IP_DO_TALK';
FLUSH PRIVILEGES;

O @'IP_DO_TALK' é a trava principal: esse usuário não consegue entrar de nenhum outro lugar, nem que a senha vaze.

2. Aceitar conexão de fora. No my.cnf ou 50-server.cnf:

bind-address = 0.0.0.0

Reinicie o serviço depois de mudar.

3. Firewall:

sudo ufw allow from IP_DO_TALK to any port 3306 proto tcp

4. CyberPanel. O painel tem trava própria: Databases › Remote MySQL, informe o IP_DO_TALK e salve. Sem isso, o usuário existe, o firewall está aberto e a conexão continua recusada.

Testar antes de cadastrar

Rode a partir do servidor do Talk — é o teste que reproduz o caminho real:

# Postgres
psql "postgres://leitor:[email protected]:5432/erp" -c 'SELECT 1'

# MySQL
mysql -h db.exemplo.com.br -u leitor -p erp -e 'SELECT 1'

# só a porta, quando nem o cliente está instalado
nc -zv db.exemplo.com.br 5432

Funcionando aqui, cadastre a conexão no Talk e use "Testar com 5 registros" no bloco Consulta SQL.

Quando não conecta

---

Usuário editor: escrever de volta no ERP

Ler do ERP e devolver informação para ele é um caso legítimo — gravar no CRM que o consultor recebeu determinado número de leads, marcar um pedido como atendido, atualizar um campo de status. Duas coisas precisam ficar claras antes.

O bloco Consulta SQL não escreve

O motor de SQL aceita apenas SELECT e WITH, e abre transação somente leitura. Um UPDATE colocado ali é recusado antes de chegar ao banco. Isso é proposital: uma consulta de leitura que roda a cada 15 minutos, com erro de WHERE, não pode ter poder de apagar a base do ERP.

O caminho da escrita é o bloco Chamar API, contra um endpoint do próprio ERP, usado dentro de um fluxo do Bridge ou do Studio. Se o ERP não tem endpoint de escrita, o caminho é criar um — um pequeno serviço com uma rota só, que recebe o dado e faz o UPDATE. Fica mais seguro do que abrir o banco para escrita pela rede, e deixa registro de quem chamou.

Criando o usuário editor mesmo assim

Quando existe esse serviço intermediário, é ele que usa o usuário editor — e o princípio é dar o mínimo, tabela por tabela, nunca ALL PRIVILEGES.

Postgres:

CREATE USER editor WITH PASSWORD 'outra-senha-longa';
GRANT CONNECT ON DATABASE erp TO editor;
GRANT USAGE ON SCHEMA public TO editor;

-- leitura ampla, escrita só onde é necessário
GRANT SELECT ON ALL TABLES IN SCHEMA public TO editor;
GRANT INSERT, UPDATE ON consultores_metricas TO editor;
GRANT UPDATE (leads_recebidos, atualizado_em) ON consultores TO editor;

-- sequências, para o INSERT conseguir gerar id
GRANT USAGE ON ALL SEQUENCES IN SCHEMA public TO editor;

O GRANT UPDATE (coluna) é a forma mais restrita: o editor altera aquelas duas colunas da tabela consultores e mais nenhuma.

MySQL e MariaDB:

CREATE USER 'editor'@'IP_DO_SERVICO' IDENTIFIED BY 'outra-senha-longa';
GRANT SELECT ON erp.* TO 'editor'@'IP_DO_SERVICO';
GRANT INSERT, UPDATE ON erp.consultores_metricas TO 'editor'@'IP_DO_SERVICO';
FLUSH PRIVILEGES;

Repare no que não foi concedido em nenhum dos dois: DELETE, DROP, TRUNCATE, ALTER. Um erro de fluxo passa a custar um registro errado, não uma tabela perdida.

Recomendações

• Um usuário por finalidade. O leitor do Lead Conversions e o editor do serviço de escrita são usuários diferentes, com senhas diferentes. Vazou um, o outro continua fechado.
• Chave de idempotência. Se o fluxo roda a cada 15 minutos e pode repetir, grave um identificador do evento e ignore repetido. Sem isso, uma reexecução soma duas vezes.
• Coluna de origem. Uma coluna origem = 'profluxus' na tabela de destino deixa claro o que veio de automação quando alguém for auditar.
• Teste em cópia. Rode a escrita primeiro contra uma base de homologação. O Testar com 5 registros protege a leitura, não a escrita por API.

Limites do motor

Toda consulta abre transação somente leitura e é interrompida aos 30 segundos. Endereços de rede interna — 10.x, 172.16.x, 192.168.x, localhost — são bloqueados, a menos que a instalação tenha PROFLUXUS_FLUXO_REDE_INTERNA=1. Blocos de código rodam em sandbox, sem rede e sem acesso a arquivo.