name: comercialrs-meta-whatsapp-migration

description: Migração do Uazapi para Meta WhatsApp Business API no ComercialRS — estado atual, colunas a criar, credenciais necessárias

ComercialRS — Migração Uazapi para Meta WhatsApp

Diagnóstico — Estado Atual (2026-05-18)

provider atual

- automations_config.provider = "uazapi" — funcionando normalmente
- URL: https://rochasales.uazapi.com
- 8 telefones configurados

Tabela `automations_config` — colunas existentes

id, automation_id, config_key, config_value, created_at, updated_at,

crm_auto_sync, crm_last_sync_count, crm_last_sync_status, crm_last_synced_at,

provider, sales_notification_phones, send_mode,

uazapi_phone, uazapi_token, uazapi_url,

user_id, webhook_mode, webhook_url

⚠️ NÃO existem colunas meta_access_token, meta_phone_number_id, meta_waba_id, meta_business_id — precisam ser criadas.

Passo a Passo

1. Criar colunas Meta na tabela

`sql

ALTER TABLE automations_config

ADD COLUMN IF NOT EXISTS meta_access_token TEXT,

ADD COLUMN IF NOT EXISTS meta_phone_number_id TEXT,

ADD COLUMN IF NOT EXISTS meta_waba_id TEXT,

ADD COLUMN IF NOT EXISTS meta_business_id TEXT;

2. Obter credenciais do Meta for Developers

3. Atualizar provider e credenciais

`sql

UPDATE automations_config SET

provider = 'meta',

meta_access_token = 'EAAxxxxxxxxxxxxxxxxxxxxxxxxxxxxx...',

meta_phone_number_id = '123456789012345',

meta_waba_id = '987654321012345',

meta_business_id = '456789123456';

4. Verificar após mudança

As edge functions dispatch-automation e send-reminders já têm código sendViaMeta — ao trocar provider = 'meta', passam a usar Meta automaticamente.

`bash

Testar via nginx

curl -X POST "https://comercialrs.rochasalesseguros.com.br/functions/v1/dispatch-automation" \

-H "apikey: $ANON_KEY" \

-H "Authorization: Bearer $ANON_KEY" \

-H "Content-Type: application/json" \

-d '{"automation_key":"whatsapp_reminders","trigger":"daily_reminder"}'

Edge Functions que já suportam Meta

- /var/www/comercialrs/supabase/functions/dispatch-automation/index.ts — sendViaMeta(), sendToMetaRecipients()

- /var/www/comercialrs/supabase/functions/send-reminders/index.ts — sendViaMeta()
- /var/www/comercialrs/supabase/functions/meta-whatsapp-send/index.ts — função específica Meta

Bug importante: REST API retorna 401 com anon key via chamada direta

Sintoma: A mesma anon key funciona no Auth API e Functions API, mas REST API retorna 401 quando chamada diretamente no Supabase.

Workaround: Chamadas REST devem ser feitas via nginx proxy (que já tem a apikey no header):

`bash

Via nginx (OK)

curl "https://comercialrs.rochasalesseguros.com.br/rest/v1/sales?limit=1" \

-H "apikey: $ANON_KEY"

Direto no Supabase (401)

curl "https://dauftiqcvgaydddoxqhh.supabase.co/rest/v1/sales?limit=1" \

-H "apikey: $ANON_KEY"

Problemas Conhecidos

1. RLS policies em `tasks` bloqueiam PostgREST via RPC

Sintoma: dispatch-automation retorna 500 ao tentar ler tasks via RPC. RPCs que fazem SELECT em tasks falham.

Causa: Faltam políticas RLS para SELECT em tasks.

Fix (via Supabase Management API):

`sql

-- Para dispatch-automation (autenticado via JWT)

CREATE POLICY "authenticated_select_tasks" ON tasks

FOR SELECT USING (true);

-- Para webhook (anônimo, via service role key)

CREATE POLICY "anon_select_tasks" ON tasks

FOR SELECT USING (true);

2. Websocket da Supabase Cloud retorna 500 — Cloudflare bloqueia

Sintoma: curl "https://dauftiqcvgaydddoxqhh.supabase.co/realtime/v1/websocket?apikey=..." → HTTP/2 500, error code: 1101

Causa: Cloudflare não permite conexões websocket na rota do Supabase Realtime.

Workaround: Polling interval no frontend reduzido de 60s → 15s (AppDataContext.tsx fallback). Realtime funciona localmente ou via IP direto, mas não através do Cloudflare proxy.

3. VPS `meta_webhook_vps.py` usa DB diferente do `dispatch-automation`

Sintoma: O webhook server na VPS recebe replies e atualiza tasks, mas o dispatch-automation (Edge Function) envia via Supabase Cloud — se usarem DBs diferentes, a correlação não funciona.

Caminho crítico (2026-05-22):

dispatch-automation (Edge Function) → Supabase Cloud (message_log + tasks)

meta_webhook_vps.py (VPS Python) → ??? (pode estar usando DB local 172.23.0.2)

Fix: meta_webhook_vps.py deve usar Supabase Cloud via Management API (REST) ou psycopg2 conectando ao endpoint cloud:

host=db.dauftiqcvgaydddoxqhh.supabase.co

port=5432

database=postgres

user=postgres

password=

O script usa 172.23.0.2 (docker local) por padrão — DEVE ser alterado para conectar ao Supabase Cloud se a intenção é correlacionar com dispatch-automation.

Importante: Para usar psycopg2 com Supabase Cloud, o IP da VPS precisa estar na allowlist do Supabase (ou usar autenticação via sslmode=require).

4. `message_log` não recebe `meta_message_id` após envio

Sintoma: Ao criar reunião, message_log tem registro com meta_message_id mas task_id = null. Quando o corretor responde, o webhook busca pelo meta_message_id e encontra o registro, mas não sabe a qual task pertence.

Causa: O dispatch-automation DEVERIA passar taskId para sendToMetaRecipients() e a função DEVERIA fazer logMessageSent() com o task_id. Código verificado: JÁ ESTÁ CORRETO — todos os 6 call sites passam taskId. Se o task_id ainda está null, significa que:

1. O Edge Function não está fazendo o upsert corretamente, OU

2. A tabela message_log não tem a coluna task_id, OU

3. O taskId passado é null no momento do envio

Diagnóstico:

`sql

SELECT meta_message_id, task_id, phone, template_name, status, created_at

FROM public.message_log

ORDER BY created_at DESC LIMIT 5;

Se task_id é NULL → o problema está no Edge Function ou na tabela.

5. Realtime publication não incluía `tasks`

Sintoma: Kanban não atualiza automaticamente quando task muda.

Fix:

`sql

ALTER PUBLICATION supabase_realtime ADD TABLE tasks;

ALTER PUBLICATION supabase_realtime ADD TABLE message_log;

ALTER PUBLICATION supabase_realtime ADD TABLE incoming_messages;

Verificar após aplicar:

`sql

SELECT tablename FROM pg_publication_tables

WHERE pubname = 'supabase_realtime';

6. `meta_webhook_vps.py` usava schema `auth.` que não existe

Sintoma: Webhook recebia messages mas não encontrava message_log, tasks, incoming_messages.

Causa: Script usava auth.message_log, auth.tasks, auth.automations_config — o schema auth não existe no Supabase (é apenas public).

Fix aplicado (2026-05-22):

`python

ANTES (ERRO)

cur.execute("SELECT id FROM auth.tasks LIMIT 1")

cur.execute("SELECT id FROM auth.message_log LIMIT 1")

cur.execute("SELECT id FROM auth.automations_config LIMIT 1")

DEPOIS (CORRETO)

cur.execute("SELECT id FROM public.tasks LIMIT 1")

cur.execute("SELECT id FROM public.message_log LIMIT 1")

cur.execute("SELECT id FROM public.automations_config LIMIT 1")

O script também usava auth.message_replies que nunca existiu — substituído por insert em public.incoming_messages.

7. VERIFY_TOKEN do webhook estava truncado

Sintoma: GET /meta-webhook/?hub.verify_token=... nunca casava.

Causa: VERIFY_TOKEN no script era 1c5265...adab (22 chars) mas o valor correto é 1c526598c56179f772be896d233badab (32 chars).

Fix: Corrigido o valor diretamente no script.

8. `meta_webhook_vps.py` usa DB local diferente do Supabase Cloud

NOTA CRÍTICA (2026-05-22): O script na VPS (meta_webhook_vps.py) conecta em 172.23.0.2 (docker Postgres local), enquanto dispatch-automation (Edge Function) escreve no Supabase Cloud. Se a intenção é que o webhook do VPS correlacione mensagens com tasks criadas pelo dispatch-automation, o script PRECISA escrever no mesmo banco — Supabase Cloud.

Opções:

1. Conectar meta_webhook_vps.py ao Supabase Cloud via psycopg2 com host db.dauftiqcvgaydddoxqhh.supabase.co (requer IP da VPS na allowlist)

2. Manter DB local + garantir que dispatch-automation também escreva no DB local via DATABASE_URL do docker

Se manter psycopg2 → Supabase Cloud, o script precisa do endpoint REST correto para atualizar tasks (ou usar RPC).

Bug importante: REST API retorna 401 com anon key via chamada direta

Sintoma: A mesma anon key funciona no Auth API e Functions API, mas REST API retorna 401 quando chamada diretamente no Supabase.

workaround: Chamadas REST devem ser feitas via nginx proxy (que já tem a apikey no header):

`bash

Via nginx (OK)

curl "https://comercialrs.rochasalesseguros.com.br/rest/v1/sales?limit=1" \

-H "apikey: $ANON_KEY"

Direto no Supabase (401)

curl "https://dauftiqcvgaydddoxqhh.supabase.co/rest/v1/sales?limit=1" \

-H "apikey: $ANON_KEY"

Estado Atual (2026-05-20)

Credenciais Meta — já configuradas

- provider = "meta" ✅
- Phone ID: 812251211981254 / +55 11 91508-1701 (verificado, ativo)
- WABA ID: 532448808878595 — Nome no Meta: "RS - Plano de Saúde" (mesmo cliente, nome diferente)
- WABA Quality: YELLOW, STANDARD throughput
- Envio direto (type: text) funciona — testado para +55 11 91494-1608 (Julietti)
- Token de envio (WABA owner): EAASNGf6ucRcBRYZC7BtZAZBKnRjDTUwkTRpPgRw1jZALy7mQxiUTf6a7zJt7BvLj9iYsht7PtphRfDp9BjgyzjUNmJUru0yTVpzVc2EZCFxbRJID052my8IynikcjOeLAuuuXCFcE9SMKTWEdNUpnS4ltpJK4iD8d3ZAckIZBffhvrBmVFDIkmU3t1eg99klwZDZD
- Token novo (Sales Planos) EAAq2Dn6CWBU... pertence a Business diferente (118162974594950) — NÃO serve para este WABA

IMPORTANTE — Dois Tokens, Dois Negócios

- Token velho (EAASNGf6ucRc...): System User com acesso ao WABA 532448808878595 (RS - Plano de Saúde). Pode ENVIAR mensagens mas NÃO pode criar templates.
- Token novo (EAAq2Dn6CWBU...): pertence ao Business 118162974594950 (Sales Planos de Saúde). Pode criar templates mas NÃO pode enviar do phone ID 812251211981254.
- Para criar templates, o token DEVE pertencer ao Business que é dono da WABA. Gere um novo token a partir do Business que é admin da WABA 532448808878595 (não do "Sales Planos de Saúde").
- Alternativa: criar templates manualmente no Meta Business Manager da WABA.

Automations na tabela

whatsapp_reminders — enabled: true, trigger_type: null

daily_briefing — enabled: true

overdue_alerts — enabled: true

risk_alerts — enabled: true

team_members com telefone

Julietti — 5511914941608

Raissa — 5511991021201

Vinicius — 5511983928504

Pietra — 5511940858953

Rafael — 5511989793356

Julia — 5511911822891

Ilano — 5511992927009

Raiany — 5511944404184

Rayca — SEM TELEFONE

Maju — SEM TELEFONE

Tabela `tasks` — colunas importantes

Tabela `automations` — colunas (não confunda com `automations_config`!)

A automations usa key — NÃO trigger!

Tabela `automations_config` — colunas

Problemas Conhecidos

1. RLS policies em `tasks` bloqueiam PostgREST via RPC

Sintoma: dispatch-automation retorna 500 ao tentar ler tasks via RPC. RPCs que fazem SELECT em tasks falham.

Causa: Faltam políticas RLS para SELECT em tasks.

Fix (via Supabase Management API):

`sql

-- Para dispatch-automation (autenticado via JWT)

CREATE POLICY "authenticated_select_tasks" ON tasks

FOR SELECT USING (true);

-- Para webhook (anônimo, via service role key)

CREATE POLICY "anon_select_tasks" ON tasks

FOR SELECT USING (true);

2. Websocket da Supabase Cloud retorna 500 — Cloudflare bloqueia

Sintoma: curl "https://dauftiqcvgaydddoxqhh.supabase.co/realtime/v1/websocket?apikey=..." → HTTP/2 500, error code: 1101

Causa: Cloudflare não permite conexões websocket na rota do Supabase Realtime.

Workaround: Polling interval no frontend reduzido de 60s → 15s (AppDataContext.tsx fallback). Realtime funciona localmente ou via IP direto, mas não através do Cloudflare proxy.

3. VPS `meta_webhook_vps.py` usa DB diferente do `dispatch-automation`

Sintoma: O webhook server na VPS recebe replies e atualiza tasks, mas o dispatch-automation (Edge Function) envia via Supabase Cloud — se usarem DBs diferentes, a correlação não funciona.

Caminho crítico才发现 (2026-05-22):

dispatch-automation (Edge Function) → Supabase Cloud (message_log + tasks)

meta_webhook_vps.py (VPS Python) → ??? (pode estar usando DB local 172.23.0.2)

Fix: meta_webhook_vps.py deve usar Supabase Cloud via Management API (REST) oupsycopg2 conectando ao endpoint cloud:

host=db.dauftiqcvgaydddoxqhh.supabase.co

port=5432

database=postgres

user=postgres

password=

O script usa 172.23.0.2 (docker local) por padrão — DEVE ser alterado para conectar ao Supabase Cloud se a intenção é correlacionar com dispatch-automation.

Importante: Para usar psycopg2 com Supabase Cloud, o IP da VPS precisa estar na allowlist do Supabase (ou usar autenticação via sslmode=require).

4. `message_log` não recebe `meta_message_id` após envio

1. O Edge Function não está fazendo o upsert corretamente, OU

2. A tabela message_log não tem a coluna task_id, OU

3. O taskId passado é null no momento do envio

Diagnóstico:

`sql

SELECT meta_message_id, task_id, phone, template_name, status, created_at

FROM public.message_log

ORDER BY created_at DESC LIMIT 5;

Se task_id é NULL → o problema está no Edge Function ou na tabela.

5. Realtime publication não incluía `tasks`

Sintoma: Kanban não atualiza automaticamente quando task muda.

Fix:

`sql

ALTER PUBLICATION supabase_realtime ADD TABLE tasks;

ALTER PUBLICATION supabase_realtime ADD TABLE message_log;

ALTER PUBLICATION supabase_realtime ADD TABLE incoming_messages;

Verificar após aplicar:

`sql

SELECT tablename FROM pg_publication_tables

WHERE pubname = 'supabase_realtime';

Bug importante: REST API retorna 401 com anon key via chamada direta

Causa: send-reminders foi projetado para cron jobs — valida x-cron-secret header e só aceita esse método de autenticação. Quando chamado pelo frontend com JWT do browser, não consegue autenticar.

Solução: Criada função test-automation que faz o mesmo trabalho mas com autenticação via JWT do Supabase:

`bash

Deploy

cd /var/www/comercialrs

SUPABASE_ACCESS_TOKEN=sbp_REDACTED \

supabase functions deploy test-automation --project-ref dauftiqcvgaydddoxqhh

- Endpoint: /functions/v1/test-automation
- Aceita JWT do usuário logado
- Envia mensagem real via Meta API para o primeiro team_member com telefone
- Funciona igual ao test-webhook (ambos usam anon key via Supabase Gateway)

Templates Meta — Regras de Criação e Envio (DESCOBERTAS POR TRIAL-ERROR)

Regras CRÍTICAS para criação de templates no Meta Business Manager:

1. Variáveis devem ser NUMERADAS ({{1}}, {{2}}, etc)

- No editor do Meta Business Manager: use o dropdown e escolha "Number" → o Meta gera {{1}}, {{2}}, etc. automaticamente

- Variáveis com nome (ex: {{título}})digitadas manualmente NÃO funcionam como parâmetros — são interpretadas como texto fixo

- Você PODE digitar {{1}} manualmente no corpo do template

- Dropdown só aparece quando o tipo é "Number" — se escolher "Text", não há dropdown, precisa digitar {{1}} manualmente

2. Variável NÃO pode estar no início nem no fim do template

- Meta rejeita: {{1}} texto (variável no início)

- Meta rejeita: texto {{1}} (variável no fim)

- Erro exato: This model contains too many variables for your extension. Reduce the number of variables or extend the message. Variables cannot be at the beginning or end of the model.

- Solução: adicione texto fixo antes e depois, ex: 🔗 {{6}} - ComercialRS

3. Parâmetros texto NÃO podem ter quebra de linha (\n) nem tabulação

- Erro exato: Param text cannot have new-line/tab characters or more than 4 consecutive spaces

- Listas dinâmicas devem ser passadas como texto EM UMA ÚNICA LINHA, separadas por | (pipe + espaço)

- Exemplo lista correta: 1. 📹 Reunião ABC - Video - 18/05 | 2. 📞 Reunião XYZ - Telefone - 19/05 - Comercial RS

- O "- Comercial RS" no final (após último | ) também é importante para evitar variável no fim

4. Cada parâmetro precisa de texto de exemplo (sample text)

- Ao criar, o campo "Insira conteúdo para {{X}}" recebe o valor real de exemplo

- Ex: para {{1}} (título): Reunião com Cliente XYZ

- Após preencher, clique em "Adicionar texto de amostra" para cada variável

5. CÓDIGO DO IDIOMA varia conforme a seleção no Meta Business Manager

- Portuguese (BR) → código API: pt_BR

- Portuguese (POR) (europeu) → código API: pt_PT (não pt_BR!)

- Se o template foi criado com idioma errado, a API retorna 404 "Template name does not exist in the translation"

- Sempre verificar qual idioma foi selecionado ao criar e usar o código correto na API

Formato correto para listas de reuniões (parâmetro único em uma linha):

1. 📹 Renata Duarte — Mensagem — 04/05/2026 às 11h06 🔗 https://app2.paineldocorretor.com.br/crm/negocios/306628f4-ed87-4086-9e5e-d20ad059ee3b | 2. 📹 OIZUMI ODONTOLOGIA — Vídeo — 30/04/2026 às 13h00 🔗 https://app2.paineldocorretor.com.br/crm/negocios/b9d132d7-0102-44a3-9bd6-d3c57dfbe299 | 3. NUTRICENTERJS — Mensagem — 04/05/2026 às 11h50 🔗 link | 4. CREMATORIO — Mensagem — 30/04/2026 às 11h10 🔗 link - Comercial RS

- Separador entre itens: |
- Emojis de canal: 📹 (video), 📞 (telefone), 💬 (mensagem)
- Texto fixo final: - Comercial RS (evita variável no fim)

Como testar se um template funciona (abordagem em 2 etapas):

`python

import requests

token = 'EAASNGf6ucRc...'

phone_id = '812251211981254'

ETAPA 1: Enviar SEM parâmetros — verifica se template existe e está aprovado

payload_sem_params = {

'messaging_product': 'whatsapp',

'to': '5511914941608',

'type': 'template',

'template': {'name': 'nome_do_template', 'language': {'code': 'pt_BR'}}

}

r = requests.post(f'https://graph.facebook.com/v21.0/{phone_id}/messages',

json=payload_sem_params, headers={'Authorization': f'Bearer {token}'}, timeout=15)

200 + message_id = template existe e está approved

400 error 132000 = template existe mas número de params está errado

400 error 132018 = há issue com os parâmetros (tipo, espaço, etc)

ETAPA 2: Enviar COM parâmetros corretos

payload_com_params = {

'messaging_product': 'whatsapp',

'to': '5511914941608',

'type': 'template',

'template': {

'name': 'nome_do_template',

'language': {'code': 'pt_BR'},

'components': [{

'type': 'body',

'parameters': [

{'type': 'text', 'text': 'valor param 1'},

{'type': 'text', 'text': 'valor param 2'}

]

}]

}

r = requests.post(f'https://graph.facebook.com/v21.0/{phone_id}/messages',

json=payload_com_params, headers={'Authorization': f'Bearer {token}'}, timeout=15)

Códigos de erro comuns:

- 132000 — Número de parâmetros não corresponde ao esperado no template
- 132018 — Problema com os parâmetros (newline/tab, mais de 4 espaços, etc.)
- 100 (Parameter name is missing) — type: "text" está faltando no parâmetro (sempre incluir)
- 132031 — Token sem permissão para enviar this template (verificar token Business)

Templates criados e testados (2026-05-20):\n\n| Nome | Status | Lang | Params | Testado |\n|------|--------|------|--------|---------|\n| nova_reuniao_criada | ✅ Aprovado | pt_BR | 6 | ✅ |\n| 1_reunioes_atrasadas_2 | ✅ Aprovado | pt_PT | 2 | ✅ |\n| suas_reunioes_de_hoje | ✅ Aprovado | pt_PT | 2 | ✅ |\n| reunioes_sem_atualizao_ha_3_dias | ✅ Aprovado | pt_PT | 2 | ✅ |\n| reuniao_atualizada_com_sucesso | ✅ Aprovado | pt_BR | 5 | ✅ |\n| lembrete_reuniao_em_30_minutos | ⏳ Aguardando aprovação | pt_BR | 3 | ⏳ |\n\nNÃO CRIADOS (user recusou): daily_briefing, weekly_closing

Descobertas importantes sobre código de idioma:

- Portuguese (BR) → código API: pt_BR
- Portuguese (POR) (europeu) → código API: pt_PT — muito importante!
- Template criado com Portuguese (POR) só funciona com pt_PT, não com pt_BR (erro 404)
- Sempre verificar o idioma selecionado no Meta Business Manager ao criar

dispatch-automation foi reescrito (v12) para usar templates Meta — não envia mais texto livre. Arquivo: /var/www/comercialrs/supabase/functions/dispatch-automation/index.ts

Funções de formatação no dispatch-automation:

`typescript

formatStatus(status) // todo→Pendente, in_progress→Iniciada, completed→Concluída

formatChannelName(ch) // video→📹 Vídeo, telefone→📞 Telefone, mensagem→💬 Mensagem

buildMeetingList(tasks) // monta lista em UMA LINHA com separador " | " (Meta não aceita \n)

2. Mensagens de automacao exigem Templates na Meta

Problema: Envios diretos via API Graph funcionam para teste, mas para automacoes em massa (diarias, Lembretes) a Meta exige Message Templates pré-aprovados.

Caminho: Session Messages (dentro da janela de 24h após o usuário iniciar) não precisam de template. Notificações proativas (sistema inicia) precisam de template aprovado.

Solução: Criar templates no Meta Business Manager (ver próxima seção).

3. `webhook_health` — erro 400 no frontend

O frontend faz query: webhook_health?id=eq.meta — a tabela não tem coluna id com valor "meta". A coluna id é UUID. A query deveria usar webhook_id=eq.meta ou similar.

4. Status Kanban — texto legível nos templates

O campo tasks.status guarda todo / in_progress / completed. Nos templates, mostrar texto legível:

`typescript

function formatStatus(status: string): string {

if (status === 'in_progress') return 'Iniciada';

if (status === 'completed') return 'Concluída';

if (status === 'todo') return 'Pendente';

return status || '';

}

5. Canal — emoji + nome nos templates

`typescript

function formatChannelName(channel: string): string {

if (channel === 'video') return '📹 Vídeo';

if (channel === 'telefone') return '📞 Telefone';

return '💬 Mensagem';

}

6. ENVIO SÓ PARA RESPONSÁVEL — não usar fallback "enviar para todos"

Regra de segurança: Se responsible_id existe, envie apenas para esse responsável. Nunca use fallback "enviar para todos".

`typescript

// ✅ CORRETO — responsável existe, tenta só ele

if (responsibleId) {

const member = members.find(m => m.id === responsibleId);

if (member && member.phone) {

const ok = await sendMetaTemplate(config, member.phone, ...);

return ok ? { sent: 1, failed: 0 } : { sent: 0, failed: 1, errors: [...] };

}

// Não tem telefone → retorna 0, não cai no fallback

return { sent: 0, failed: 0, errors: ['sem telefone'] };

}

// Sem responsável → retorna 0, não "envia para todos"

return { sent: 0, failed: 0, errors: ['sem responsável'] };

Por que importa: Se o responsável não tem telefone → sent: 0 (erro logged). Não enviar para todos os 9 membros do time — isso é spam.

7. Dois tipos de envio: individual vs broadcast

`typescript

// Para triggers INSTANT (task_created, task_updated, meeting_alert_30min)

// → sendToMetaRecipients(responsibleId) // só o responsável

// Se não tem responsible_id → não envia para ninguém (sent: 0)

// Para triggers SCHEDULED/BROADCAST (whatsapp_reminders, overdue_alerts, risk_alerts)

// → broadcastMetaTemplate() // todos os membros com telefone

8. Status Kanban — texto legível nos templates

`typescript

function formatStatus(status: string): string {

if (status === 'in_progress') return 'Iniciada';

if (status === 'completed') return 'Concluída';

if (status === 'todo') return 'Pendente';

return status || '';

}

9. Canal — emoji + nome nos templates

`typescript

function formatChannelName(channel: string): string {

if (channel === 'video') return '📹 Vídeo';

if (channel === 'telefone') return '📞 Telefone';

return '💬 Mensagem';

}

10. Bug: Token Meta revertendo ao trocar de tab (useEffect race condition)

Sintoma: O token meta_access_token no painel de Automações revertia ao trocar de tab, mesmo aparecendo corretamente no banco.

Causa Raiz: Race condition no useEffect que salvava draft no localStorage. O efeito tinha loading como dependência — ao completar o loadData, loading mudava de true→false, disparando o efeito que sobreescrevia o draft com valores intermediários do estado.

Arquivo com bug: /var/www/comercialrs/src/components/automations/AutomationsPanel.tsx

Fix aplicado:

`tsx

// ANTES (bugado) — loading nas dependências dispara no primeiro load

useEffect(() => {

if (loading || !userHasEdited) return;

localStorage.setItem(AUTOMATIONS_DRAFT_KEY, JSON.stringify(draft));

}, [loading, userHasEdited, draft]);

// DEPOIS (correto) — isFirstLoad ref bloqueia no mount inicial

const isFirstLoad = useRef(true);

// ...

useEffect(() => {

if (!userHasEdited || isFirstLoad.current) return;

localStorage.setItem(AUTOMATIONS_DRAFT_KEY, JSON.stringify(draft));

}, [userHasEdited, draft]);

// E no final do loadData():

isFirstLoad.current = false;

Padrão reutilizável: Sempre que um useEffect salvar estado no localStorage ou em outro storage externo, usar useRef(true) como "bloqueio de primeira execução" E remover dependências que mudam no mount inicial (loading, isLoading, data, etc.).

11. buildMeetingList — lista em uma linha (Meta não aceita \n)

`typescript

function buildMeetingList(tasks: Task[]): string {

return tasks.map((t, i) => {

const dateStr = formatDateBR(t.due_date);

const timeStr = formatTimeBR(t.due_date);

const ch = formatChannelEmoji(t.channel || 'mensagem');

const timePart = timeStr ? ${timeStr} : '';

return ${i + 1}. ${ch} ${t.title} — ${dateStr}${timePart} 🔗 ${t.link || ''};

}).join(' | ') + ' - Comercial RS';

}

Templates Meta — Plano de Criação (2026-05-20)

Acessar: Meta Business Manager → WhatsApp → Message Templates

⚠️ ANTES DE CRIAR: O token atual (EAASNGf6ucRc...) é de System User que SÓ pode enviar, não pode criar templates.

Você precisa criar manualmente no Business Manager OU gerar token de um admin da WABA 532448808878595.

Após criar, aguarde aprovação (1-24h) e me informe os nomes exatos + número de parâmetros.

8 Templates a criar

Parâmetros detalhados

task_created (6 params):

1. {{1}} = tasks.title

2. {{2}} = team_members.name (pelo responsible_id)

3. {{3}} = tasks.channel formatado (📹 Vídeo / 📞 Telefone / 💬 Mensagem)

4. {{4}} = tasks.due_date → data 20/05/2026

5. {{5}} = tasks.due_date → hora 14:30

6. {{6}} = tasks.link

meeting_alert_30min (3 params):

1. {{1}} = tasks.title

2. {{2}} = tasks.due_date → hora 14:30

3. {{3}} = tasks.link

meetings_overdue_summary (2 params):

1. {{1}} = COUNT de tasks com due_date < hoje E status != completed,cancelled

2. {{2}} = lista em UMA LINHA com | como separador (ex: 1. 📹 Título - Video - 18/05 | 2. 📞 Título - Telefone - 19/05)

whatsapp_reminders (2 params):

1. {{1}} = data hoje (pt-BR)

2. {{2}} = lista das reuniões do dia (formato: 1. 📹 Título - Video - 20/05 às 14:30 | 2. 📞 Título - Telefone - 20/05 às 16:00)

risk_alerts (2 params):

1. {{1}} = COUNT de tasks com due_date < (hoje - 3 dias) E status = todo

2. {{2}} = lista em UMA LINHA com | como separador

daily_briefing (4 params):

1. {{1}} = data hoje

2. {{2}} = total reuniões hoje

3. {{3}} = concluídas hoje

4. {{4}} = pendentes hoje (= total - concluídas)

weekly_closing (1 param):

1. {{1}} = COUNT tasks com status=completed E updated_at >= (hoje - 7 dias)

task_updated (5 params):

1. {{1}} = tasks.title

2. {{2}} = tasks.due_date → data

3. {{3}} = tasks.due_date → hora

4. {{4}} = tasks.status → texto (a fazer / em andamento / concluída)

5. {{5}} = tasks.link

Fluxo completo de triggers WhatsApp (dispatch-automation v12+)

Regra clara:

- INSTANT com responsible_id → sendToMetaRecipients() (só o responsável, SEM fallback)
- BROADCAST → broadcastMetaTemplate() (todos os membros com telefone)

Campo	Onde encontrar
---	---
`meta_access_token`	Meta for Developers → App → WhatsApp → Configuration → Permanent Token
`meta_phone_number_id`	Meta for Developers → App → WhatsApp → Phone Numbers → ID da sua linha
`meta_waba_id`	Meta Business Account → WhatsApp Business → Settings → WABA ID
`meta_business_id`	Meta Business Account → Settings → Business Info → Business ID
coluna	tipo	descrição
--------	------	-----------
`id`	uuid
`title`	text	Título da reunião
`due_date`	timestamptz	`2026-05-20T14:30`
`channel`	text	`video` / `telefone` / `mensagem`
`link`	text	Link da reunião
`status`	text	`todo` / `in_progress` / `completed` / `cancelled`
`responsible_id`	uuid	FK para `team_members.id`
`priority`	text	`low` / `medium` / `high` / `urgent`
`deleted_at`	timestamptz	Soft delete
coluna	tipo	descrição
--------	------	-----------
`id`	uuid
`key`	text	Identificador: `task_created`, `whatsapp_reminders`, `daily_briefing`, `risk_alerts`, `weekly_closing`, `overdue_alerts`
`name`	text	Nome exibido
`description`	text
`trigger_type`	jsonb	Não usado no código
`action_type`	jsonb	Não usado no código
`enabled`	boolean
`status`	text	`active` / `inactive`
`last_run_at`	timestamptz
coluna	tipo	descrição
--------	------	-----------
`id`	uuid
`provider`	text	`meta` ou `uazapi`
`meta_access_token`	text	Token Meta
`meta_phone_number_id`	text	`812251211981254`
`meta_waba_id`	text	`532448808878595`
`meta_business_id`	text	`1264409148885415`
`uazapi_url`	text
`uazapi_token`	text
`uazapi_phone`	text
`sales_notification_phones`	text	phones separadas por vírgula
`crm_auto_sync`	boolean
`send_mode`	text	`personal`
Nome	Categoria	Params	Body
------	-----------	--------	------
`task_created`	TRANSACTIONAL	6	📹 Nova Reunião Criada\\n📌 {{1}}\\n👤 Responsável: {{2}}\\n📹 {{3}} — {{4}} às {{5}}\\n🔗 {{6}} - ComercialRS
`meeting_alert_30min`	TRANSACTIONAL	3	⏰ Lembrete: Reunião em 30 minutos\\n📌 {{1}}\\n🕐 {{2}}\\n🔗 {{3}} - ComercialRS
`meetings_overdue_summary`	MARKETING	2	🚨 {{1}} reunião(ões) atrasada(s):\n\n{{2}}
`whatsapp_reminders`	TRANSACTIONAL	2	📅 Suas reuniões de hoje ({{1}}):\n\n{{2}}
`risk_alerts`	MARKETING	2	⚠️ Alerta: {{1}} reunião(ões) sem atualização há 3+ dias:\n\n{{2}}
`daily_briefing`	MARKETING	4	📊 Briefing Diário ({{1}})\n\n📅 Reuniões hoje: {{2}}\n✅ Concluídas: {{3}}\n⏳ Pendentes: {{4}}
`weekly_closing`	MARKETING	1	🏁 Encerramento Semanal\n\n✅ {{1}} reunião(ões) encerrada(s) esta semana!
`task_updated`	TRANSACTIONAL	5	✅ Reunião atualizada com sucesso!\n📌 {{1}}\n📅 {{2}} às {{3}}\n📊 Status: {{4}}\n🔗 {{5}}
trigger/key	Quando	Destinatário	Tipo	Template
---	---	---	---	---
`task_created`	Nova reunião criada	responsible_id	INSTANT	`nova_reuniao_criada` (pt_BR, 6 params) ✅
`task_updated`	Atualização na reunião	responsible_id	INSTANT	`reuniao_atualizada_com_sucesso` (pt_BR, 5 params) ✅
`meeting_alert_30min`	30min antes da reunião	responsible_id	INSTANT	`lembrete_reuniao_em_30_minutos` (pt_BR, 3 params) ⏳
`meetings_overdue_summary`	Tarefas vencidas (instant)	TODOS (broadcast)	INSTANT	`1_reunioes_atrasadas_2` (pt_PT, 2 params) ✅
`whatsapp_reminders`	Reuniões do dia (cron)	TODOS (broadcast)	SCHEDULED	`suas_reunioes_de_hoje` (pt_PT, 2 params) ✅
`overdue_alerts`	Tarefas vencidas (cron)	TODOS (broadcast)	SCHEDULED	`1_reunioes_atrasadas_2` (pt_PT, 2 params) ✅
`risk_alerts`	3+ dias sem movimento (cron)	TODOS (broadcast)	SCHEDULED	`reunioes_sem_atualizao_ha_3_dias` (pt_PT, 2 params) ✅
Funcao	Proposito	Autenticacao	Provider
--------	-----------	--------------	----------
`dispatch-automation`	Notificacoes INSTANTANEAS e SCHEDULED	JWT (verify_jwt: true)	meta ou uazapi
`send-reminders`	Cron jobs / resumos agendados	x-cron-secret	meta, uazapi ou n8n
`test-webhook`	Testar conexao do provider (Settings)	anon key	meta ou n8n
`test-automation`	Testar envio real de WhatsApp via automacao	JWT (anon key funciona)	meta

Fluxo de notificacao:

1. Frontend ou cron dispara dispatch-automation com trigger: "task_created" e payload contendo a task

2. dispatch-automation busca responsible_id da task → encontra phone em team_members

3. Envia via sendToMetaRecipients() para o telefone do responsavel

4. tambem envia fallback para todos com telefone se responsible_id vazio

WhatsApp Bidirecional (2026-05-21)

Problema

Corretores recebem notificação quando reunião é atribuída, mas ao responder o WhatsApp (ex: "iniciada", "concluída") a task não é atualizada no ComercialRS.

Arquitetura implementada

Corretor recebe template → responde no WhatsApp → Meta chama meta-webhook

→ parseia resposta → busca task por message_log.meta_message_id (via context.id)

→ valida responsible_id → atualiza tasks.status → confirma via WhatsApp

Tabelas criadas (2026-05-21)

`sql

-- LOG de mensagens enviadas (para correlacionar resposta → task)

CREATE TABLE message_log (

id UUID PRIMARY KEY DEFAULT gen_random_uuid(),

meta_message_id TEXT UNIQUE, -- wamid.xxx (ID da msg na Meta)

task_id UUID REFERENCES tasks(id),

responsible_id UUID REFERENCES team_members(id),

template_name TEXT,

sent_at TIMESTAMPTZ DEFAULT NOW(),

phone TEXT,

status TEXT DEFAULT 'sent'

);

-- Log de respostas recebidas

CREATE TABLE message_replies (

id UUID PRIMARY KEY DEFAULT gen_random_uuid(),

message_log_id UUID REFERENCES message_log(id),

meta_message_id TEXT,

from_phone TEXT,

response_text TEXT,

parsed_status TEXT,

task_id UUID REFERENCES tasks(id),

processed_at TIMESTAMPTZ DEFAULT NOW()

);

-- Incoming messages (já existia meta-webhook tentando gravar aqui)

CREATE TABLE incoming_messages (

id UUID PRIMARY KEY DEFAULT gen_random_uuid(),

message_id TEXT UNIQUE,

from_number TEXT,

timestamp TEXT,

msg_type TEXT,

body TEXT,

source TEXT DEFAULT 'meta_webhook',

created_at TIMESTAMPTZ DEFAULT NOW()

);

-- Coluna na tasks para guardar o último message_id enviado

ALTER TABLE tasks ADD COLUMN IF NOT EXISTS last_meta_message_id TEXT;

-- Índices

CREATE INDEX idx_message_log_meta_message_id ON message_log(meta_message_id);

CREATE INDEX idx_message_log_task_id ON message_log(task_id);

CREATE INDEX idx_message_log_responsible_id ON message_log(responsible_id);

CREATE INDEX idx_message_replies_message_log_id ON message_replies(message_log_id);

CREATE INDEX idx_message_replies_meta_message_id ON message_replies(meta_message_id);

CREATE INDEX idx_message_replies_task_id ON message_replies(task_id);

CREATE INDEX idx_incoming_messages_message_id ON incoming_messages(message_id);

CREATE INDEX idx_incoming_messages_from_number ON incoming_messages(from_number);

RLS policies

`sql

-- message_log: service role full, anon read (para webhook correlacionar)

CREATE POLICY "service_role_full_access_message_log" ON message_log FOR ALL USING (auth.jwt() ->> 'role' = 'service_role');

CREATE POLICY "anon_read_message_log" ON message_log FOR SELECT USING (true);

-- message_replies: service role full, anon insert (webhook recebe replies)

CREATE POLICY "service_role_full_access_message_replies" ON message_replies FOR ALL USING (auth.jwt() ->> 'role' = 'service_role');

CREATE POLICY "anon_insert_message_replies" ON message_replies FOR INSERT WITH CHECK (true);

-- incoming_messages

CREATE POLICY "service_role_full_incoming" ON incoming_messages FOR ALL USING (auth.jwt() ->> 'role' = 'service_role');

CREATE POLICY "anon_insert_incoming" ON incoming_messages FOR INSERT WITH CHECK (true);

-- tasks: service role pode atualizar (webhook precisa atualizar status)

CREATE POLICY "service_role_update_tasks" ON tasks FOR UPDATE USING (auth.jwt() ->> 'role' = 'service_role');

Como a resposta é correlacionada

Quando o corretor responde a uma mensagem de template, a Meta envia no webhook:

`json

{

"messages": [{

"context": { "from": "...", "id": "wamid.xxx" }, // ← ID da msg original

"from": "5511914941608",

"text": { "body": "iniciada" }

}]

}

O webhook busca message_log WHERE meta_message_id = 'wamid.xxx' → encontra task_id → valida responsible_id → atualiza.

Modificações no dispatch-automation

- sendMetaTemplate agora retorna { ok: boolean, messageId?: string, error?: string } em vez de boolean
- logMessageSent() fire-and-forget registra cada envio em message_log
- sendToMetaRecipients() recebe novo parâmetro taskId e loga após envio

Deploy

`bash

cd /var/www/comercialrs

SUPABASE_ACCESS_TOKEN=sbp_REDACTED \

supabase functions deploy dispatch-automation --project-ref dauftiqcvgaydddoxqhh

Webhook Bidirecional — Como a resposta é correlacionada

Quando o corretor responde a uma mensagem de template, a Meta envia no webhook:

`json

{

"messages": [{

"context": { "from": "...", "id": "wamid.xxx" }, // ← ID da msg original

"from": "5511914941608",

"text": { "body": "iniciada" }

}]

}

O webhook busca message_log WHERE meta_message_id = 'wamid.xxx' → encontra task_id → valida responsible_id → atualiza.

⚠️ PROBLEMA CRÍTICO DESCOBERTO: Supabase Edge Functions exige JWT

O endpoint /functions/v1/ do Supabase SEMPRE exige autenticação JWT válida, mesmo para webhooks GET de verificação. Isso impede que a Meta consiga fazer o handshake inicial de verificação.

Sintomas:

- GET /functions/v1/meta-webhook com anon key → UNAUTHORIZED_NO_AUTH_HEADER
- GET /functions/v1/meta-webhook com Bearer token → UNAUTHORIZED_LEGACY_JWT (JWT antigo da era v0/v1 não é mais aceito)
- Meta nunca consegue verificar → muestra "Não foi possível validar a URL de callback"

Solução implementada (2026-05-21):

1. Servidor Python standalone na porta 8082 (ou 8081 se livre):

- Arquivo: /var/www/comercialrs/data/meta_webhook_server.py

- Sem autenticação JWT — só verifica o hub.verify_token da query string

- Processa POST payloads e atualiza tasks via Supabase REST API com Service Role key

2. Nginx proxy em /etc/nginx/snippets/meta-webhook-proxy.conf:

`nginx

location /meta-webhook/ {

proxy_pass http://127.0.0.1:8082/;

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header X-Forwarded-Proto $scheme;

proxy_http_version 1.1;

proxy_request_buffering off;

proxy_read_timeout 300;

}

- Incluir no site Nginx: include /etc/nginx/snippets/meta-webhook-proxy.conf;

3. URL cadastrada na Meta:

- https://comercialrs.rochasalesseguros.com.br/meta-webhook/ (NÃO a /functions/v1/)

4. Service systemd (para manter rodando após reboot):

`ini

[Unit]

Description=Meta WhatsApp Webhook Server

After=network.target

[Service]

Type=simple

User=root

WorkingDirectory=/var/www/comercialrs/data

ExecStart=/usr/bin/python3 /var/www/comercialrs/data/meta_webhook_server.py

Restart=always

RestartSec=5

StandardOutput=append:/var/www/comercialrs/data/meta_webhook.log

StandardError=append:/var/www/comercialrs/data/meta_webhook.log

[Install]

WantedBy=multi-user.target

`bash

Ativar

systemctl daemon-reload

systemctl enable meta-webhook

systemctl start meta-webhook

Verificar

curl http://127.0.0.1:8082/?hub.mode=subscribe&hub.verify_token=TOKEN&hub.challenge=OK

⚠️ PORTA CORRETA: 8082 (NÃO 8083)

Problema comum (2026-05-27): O nginx estava configurado com proxy_pass http://127.0.0.1:8083/ mas o servidor Python ouvinte em 8082 (não 8083). Resultado: todos os webhooks retornavam 502 Bad Gateway e eram perdidos.

Arquivos com a porta no nginx:

`bash

grep -rn '8083' /etc/nginx/

/etc/nginx/snippets/meta-webhook-proxy.conf:5: proxy_pass http://127.0.0.1:8083/;

/etc/nginx/sites-available/comercialrs.rochasalesseguros.com.br:64: proxy_pass http://127.0.0.1:8083/;

Correção aplicada (2026-05-27): Ambos mudados para 8082.

Como diagnosticar:

`bash

1. Verificar porta real do servidor Python

ss -tlnp | grep python

2. Testar localmente

curl -X POST http://127.0.0.1:8082/ -d '{"object":"whatsapp_business_account"}' -H 'Content-Type: application/json'

Esperado: 200

3. Verificar nginx logs

tail /var/log/nginx/error.log | grep 502

4. Testar via HTTPS (como Meta vê)

curl -X POST https://comercialrs.rochasalesseguros.com.br/meta-webhook/ -d '{"object":"whatsapp_business_account"}' -H 'Content-Type: application/json'

Esperado: 200

Sintoma do problema: Mensagens WhatsApp eram enviadas com sucesso (200 OK do Meta), mas o Chatwoot nunca atualizava. Isso porque o nginx descartava os webhooks de resposta (502) e eles nunca chegavam ao servidor Python.

5. Importante: deploy-vps-meta-1 no Docker é o Postgres-meta (supabase metadata API), NÃO tem nada a ver com WhatsApp. Parar esse container não afeta webhooks.

6. O Edge Function /functions/v1/meta-webhook continua existindo — pode ser útil para testes locais via supabase functions serve, mas NÃO é usado para o webhook real da Meta.

7. Chatwoot não é afetado — usa configuração Nginx separada (não conflita com o snippet de proxy)

Modificações no dispatch-automation (2026-05-21)

Credenciais de acesso

- Login ComercialRS: tecrochasales@gmail.com / Rochasales2024

- Supabase Dashboard: sales.planoss@gmail.com / tSm?p8n57f+TX5n
- Projeto Supabase: dauftiqcvgaydddoxqhh
- Anon key: eyJ_REDACTED
- Supabase Management API Token: sbp_REDACTED
- Meta User Access Token: EAASNGf6ucRcBRYZC7BtZAZBKnRjDTUwkTRpPgRw1jZALy7mQxiUTf6a7zJt7BvLj9iYsht7PtphRfDp9BjgyzjUNmJUru0yTVpzVc2EZCFxbRJID052my8IynikcjOeLAuuuXCFcE9SMKTWEdNUpnS4ltpJK4iD8d3ZAckIZBffhvrBmVFDIkmU3t1eg99klwZDZD

ComercialRS — Migração Uazapi para Meta WhatsApp

Diagnóstico — Estado Atual (2026-05-18)

provider atual

Tabela automations_config — colunas existentes

Passo a Passo

1. Criar colunas Meta na tabela

2. Obter credenciais do Meta for Developers

3. Atualizar provider e credenciais

4. Verificar após mudança

Testar via nginx

Edge Functions que já suportam Meta

Bug importante: REST API retorna 401 com anon key via chamada direta

Via nginx (OK)

Direto no Supabase (401)

Problemas Conhecidos

1. RLS policies em tasks bloqueiam PostgREST via RPC

2. Websocket da Supabase Cloud retorna 500 — Cloudflare bloqueia

3. VPS meta_webhook_vps.py usa DB diferente do dispatch-automation

4. message_log não recebe meta_message_id após envio

5. Realtime publication não incluía tasks

6. meta_webhook_vps.py usava schema auth. que não existe

ANTES (ERRO)

DEPOIS (CORRETO)

7. VERIFY_TOKEN do webhook estava truncado

8. meta_webhook_vps.py usa DB local diferente do Supabase Cloud

Bug importante: REST API retorna 401 com anon key via chamada direta

Via nginx (OK)

Direto no Supabase (401)

Estado Atual (2026-05-20)

Credenciais Meta — já configuradas

IMPORTANTE — Dois Tokens, Dois Negócios

Automations na tabela

team_members com telefone

Tabela tasks — colunas importantes

Tabela automations — colunas (não confunda com automations_config!)

Tabela automations_config — colunas

Problemas Conhecidos

1. RLS policies em tasks bloqueiam PostgREST via RPC

2. Websocket da Supabase Cloud retorna 500 — Cloudflare bloqueia

3. VPS meta_webhook_vps.py usa DB diferente do dispatch-automation

4. message_log não recebe meta_message_id após envio

5. Realtime publication não incluía tasks

Bug importante: REST API retorna 401 com anon key via chamada direta

Deploy

ETAPA 1: Enviar SEM parâmetros — verifica se template existe e está aprovado

200 + message_id = template existe e está approved

400 error 132000 = template existe mas número de params está errado

400 error 132018 = há issue com os parâmetros (tipo, espaço, etc)

ETAPA 2: Enviar COM parâmetros corretos

2. Mensagens de automacao exigem Templates na Meta

3. webhook_health — erro 400 no frontend

4. Status Kanban — texto legível nos templates

5. Canal — emoji + nome nos templates

6. ENVIO SÓ PARA RESPONSÁVEL — não usar fallback "enviar para todos"

7. Dois tipos de envio: individual vs broadcast

8. Status Kanban — texto legível nos templates

9. Canal — emoji + nome nos templates

10. Bug: Token Meta revertendo ao trocar de tab (useEffect race condition)

11. buildMeetingList — lista em uma linha (Meta não aceita \n)

Templates Meta — Plano de Criação (2026-05-20)

8 Templates a criar

Parâmetros detalhados

Fluxo completo de triggers WhatsApp (dispatch-automation v12+)

WhatsApp Bidirecional (2026-05-21)

Problema

Arquitetura implementada

Tabelas criadas (2026-05-21)

RLS policies

Como a resposta é correlacionada

Modificações no dispatch-automation

Deploy

Webhook Bidirecional — Como a resposta é correlacionada

⚠️ PROBLEMA CRÍTICO DESCOBERTO: Supabase Edge Functions exige JWT

Ativar

Verificar

⚠️ PORTA CORRETA: 8082 (NÃO 8083)

/etc/nginx/snippets/meta-webhook-proxy.conf:5: proxy_pass http://127.0.0.1:8083/;

/etc/nginx/sites-available/comercialrs.rochasalesseguros.com.br:64: proxy_pass http://127.0.0.1:8083/;

1. Verificar porta real do servidor Python

2. Testar localmente

Tabela `automations_config` — colunas existentes

1. RLS policies em `tasks` bloqueiam PostgREST via RPC

3. VPS `meta_webhook_vps.py` usa DB diferente do `dispatch-automation`

4. `message_log` não recebe `meta_message_id` após envio

5. Realtime publication não incluía `tasks`

6. `meta_webhook_vps.py` usava schema `auth.` que não existe

8. `meta_webhook_vps.py` usa DB local diferente do Supabase Cloud

Tabela `tasks` — colunas importantes

Tabela `automations` — colunas (não confunda com `automations_config`!)

Tabela `automations_config` — colunas

1. RLS policies em `tasks` bloqueiam PostgREST via RPC

3. VPS `meta_webhook_vps.py` usa DB diferente do `dispatch-automation`

4. `message_log` não recebe `meta_message_id` após envio

5. Realtime publication não incluía `tasks`

3. `webhook_health` — erro 400 no frontend