Menuabrir
Em fluxoAtualizado em 14 de mai. de 2026, 00:06

Este módulo depende de

4
  • whatsappAgrega status de instâncias Evolution/Meta Cloud (whatsapp_provider_account)
  • instagramAgrega status de contas Instagram conectadas
  • billingAgrega status de credenciais Asaas (tenant_provider_credentials)
  • settingsAgrega status de providers configurados (Brevo, Daily, Bunny)

Módulos que dependem deste

0

Nenhum módulo depende deste hoje.

Connections

Status: 🟡 Em fluxo (hub centralizado de status — sem tabelas próprias) Code: backend/app/modules/connections UI: frontend/src/app/(admin)/[slug]/admin/connections Última revisão deste doc: 2026-05-13 por Felipe + Claude Dependências fortes: lê de whatsapp/instagram/billing/settings (não escreve)


1. Identidade

O que faz (uma frase)

Hub read-only que agrega status de integrações (WhatsApp Evolution/Meta Cloud, Instagram, Email Brevo, Video Daily/Bunny, Billing Asaas) — exibe num lugar só "o que está conectado, qual saúde, se token expirou".

Por que existe (negócio)

Sem este módulo, Felipe abre 5 telas diferentes pra ver se tudo está funcionando. Com Connections:

  • 1 página /admin/connections mostra tudo.
  • Health Evolution (score por instância).
  • Meta Cloud token válido?
  • Instagram conta ativa?
  • Daily/Bunny configurados?

Status atual

Em fluxo — base read-only funciona, mas writes ainda delegados aos módulos donos (whatsapp, settings).

Próxima mudança: OAuth flows centralizados aqui (hoje espalhados).


2. Cases de uso reais

Case 1: Felipe verifica saúde de tudo

UI /admin/connections → backend chama:

  • WhatsApp: whatsapp_provider_account + whatsapp_provider_health (score por account).
  • Instagram: instagram_account ativos.
  • Email: env var Brevo configurada?
  • Video: env vars Daily + Bunny.
  • Billing: tenant_provider_credentials provider=asaas status=active.

Página mostra cards verde/amarelo/vermelho.


3. Oportunidades de negócio

  • Centralized OAuth flows: hoje espalhados, mover pra Connections seria UX killer.
  • Health alerts: se algo degrada, notify admin.
  • Multi-provider per tenant: suportar N providers de email/billing.

4. Arquitetura interna

Arquivos

Tasks

Sem Celery. Status sob demanda.


5. Tabelas

0 tabelas próprias. Lê de:

  • whatsapp_provider_account + whatsapp_provider_health
  • instagram_account
  • tenant_provider_credentials

6. API / Endpoints (7)

Prefixo /api/connections.

MétodoRotaO que faz
GET/whatsappLista instâncias com status real (queries Evolution ou Meta Cloud Graph API)
POST/whatsappCria nova instância (Evolution ou Meta Cloud)
PATCH/whatsapp/{id}Atualiza label ou is_active
GET/instagramStatus conta IG conectada
GET/emailProvedor configurado (Brevo/SMTP/etc.)
GET/video{daily_configured, bunny_configured}
GET/billing{provider: "asaas", configured: bool}

7. Configuração

Env vars (consumidas, não definidas)

  • WhatsApp: EVOLUTION_API_URL, EVOLUTION_API_KEY.
  • Email: EMAIL_PROVIDER, BREVO_SENDER_EMAIL.
  • Video: DAILY_API_KEY, BUNNY_STREAM_API_KEY.

8. Operações + Troubleshooting

Sintoma: Health WhatsApp stale

Causa: whatsapp_provider_health.checked_at > 1h. Fix: UI deve avisar "última check em X minutos". Trigger manual via whatsapp.tasks.score_health_all.

Sintoma: Meta Cloud HTTP timeout em GET /connections/whatsapp

Causa: Service faz HTTP síncrono pra Graph API. Fix: Refactor pra async queue futuro.


9. Limitações e débitos técnicos

#Item
1Read-only — writes em outros módulos
2Meta Cloud HTTP síncrono — pode timeout
3Health stale
4Email provider singular
5Sem OAuth centralizado

10. Histórico

Em fluxo desde Suite v2. Refactor pra OAuth centralizado é roadmap.