# Conectores e canais

Se a [camada de dados](/pt-BR/docs/ia/seu-app-como-camada-de-dados) é sobre o que uma IA pode ler e fazer **dentro** do seu app, esta página é sobre as **pontes para fora**: sincronizar com provedores externos (o Google Calendar, o Stripe) e — o que o fundador mais pergunta — atender por canais de mensagem como o WhatsApp.

Parte disso já está em produção. Parte é roadmap, e aqui a gente diz claramente qual é qual. Para a lista completa de provedores do catálogo (com o status de cada um), veja a página de [Integrações](/pt-BR/docs/plugins/integracoes).

## A espinha de conectores

Existe um contrato real de conectores em `@fayz-ai/core` (`packages/core/src/integrations`): `Connector` e `ConnectorDefinition`. Um conector declara:

- **Um modo de autenticação** — `oauth`, `api-key` ou `mtls`.
- **Capacidades** — o que ele sabe sincronizar.
- **`testConnection` e `sync`** — testar a credencial e puxar/empurrar dados.

Um plugin publica conectores pelo campo `connectors` do manifesto (o plugin vira um addon de um host). A shell traz um **ConnectorsHub** compartilhado nas configurações, onde o usuário conecta e gerencia provedores. O trabalho pesado de sincronização roda em **Supabase Edge Functions** — o plano de dados fica no backend, não no navegador.

{% callout type="tip" %}
Pense em dois planos: o **control plane** é a UI de `/settings` (conectar, testar, escolher o que sincronizar); o **data plane** é a edge function que faz o sync de verdade. O contrato em `@fayz-ai/core` costura os dois.
{% /callout %}

## Dois conectores que já existem

Não é teoria — há dois POCs shipados:

{% cards %}
{% card title="Google Calendar" icon="📅" %}
No `plugin-agenda`: OAuth, seletor de calendário e sync de eventos. Vive em `src/integrations/google-calendar`. É o exemplo canônico de conector nativo de um plugin.
{% /card %}
{% card title="Stripe" icon="💳" %}
No `plugin-courses`: conector de pagamentos em `src/connectors/stripe.ts`. Mostra o mesmo contrato aplicado a um provedor de billing.
{% /card %}
{% /cards %}

Os dois seguem o mesmo `ConnectorDefinition` — é o padrão que um plugin próprio replica para falar com qualquer provedor externo.

## Canais de mensagem — e o WhatsApp

Aqui entra o que o fundador cobra: **como esses produtos chegam ao WhatsApp**. A resposta honesta tem duas partes — a base que já existe e o marco que ainda vem.

### O que existe: o inbox omni-channel

O `plugin-conversations` é um **inbox omni-channel experimental**. O enum de canais já inclui `whatsapp` como rótulo, e o plugin declara as `aiTools` `listConversations` (`read`) e `sendMessage` (`persist`). Ou seja: a **estrutura** de caixa de entrada, threads e ferramentas de IA para ler e responder **já está modelada**.

{% badge status="experimental" %}

O que **não** existe ainda: o provedor é **mock**. Não há integração real de mensagens. Nenhuma mensagem de WhatsApp entra ou sai hoje.

### O que vem: conectores reais de canal

O próprio README do plugin-conversations diz qual é o próximo marco, sem rodeios:

> "Real channel connectors — Twilio, WhatsApp Cloud, Meta, IMAP — are the next milestone."

{% callout type="warn" %}
**WhatsApp é roadmap.** Ainda não existe configuração real de WhatsApp, Twilio ou Meta na SDK. Qualquer tela que sugira o contrário seria falsa. O que existe é o inbox experimental (mock) e o contrato de conectores pronto para receber esses provedores.
{% /callout %}

### O fluxo-alvo: atendimento com IA no WhatsApp

Quando os conectores de canal chegarem, a base já está desenhada para isto — some as duas metades desta seção:

```
WhatsApp Cloud API  ──▶  conector de canal  ──▶  plugin-conversations (inbox)
                                                        │
                                    aiTools (listConversations, sendMessage)
                                                        │
                                                   seu endpoint + LLM
                                                        │
                                          responde no WhatsApp com contexto
                                          real do tenant (agenda, pedidos…)
```

O inbox recebe a mensagem por um conector real; as `aiTools` de conversations (mais as dos outros plugins) dão ao agente o que ler e fazer; seu endpoint roda o LLM; a resposta volta pelo mesmo canal. **Inbox + aiTools = atendimento com IA no WhatsApp** — a arquitetura é essa, e o que falta é o conector de canal, não o resto.

## MCP: em breve

Um **MCP server** dedicado da Fayz — para o agente consultar catálogo e docs sem colar URLs — está em fase de design (só docs por enquanto). Até lá, o caminho oficial é o [`llms.txt` e as páginas `.md`](/pt-BR/docs/ia/conecte-seu-agente).

---

Veja também: [Seu app como camada de dados](/pt-BR/docs/ia/seu-app-como-camada-de-dados) e o campo `connectors` no [Manifesto do plugin](/pt-BR/docs/referencia/plugin-manifest).