# Integrações

O Fayz tem um **catálogo de integrações** — provedores externos que um app pode conectar: bancos de dados, gateways de pagamento, agendas, canais de mensagem, analytics e modelos de IA. Esta página lista o catálogo direto da fonte da verdade da plataforma e diz, sem maquiar, **o que já tem conector real no SDK hoje** versus o que é catálogo/roadmap.

A régua importa: um item no catálogo **não** significa que existe um conector pronto para plugar. Significa que o provedor está mapeado e o caminho de conexão está desenhado. Os badges de cada card contam a verdade.

## Como ler os status

- **Conector no SDK** — existe um `ConnectorDefinition` real, hospedado dentro de um plugin publicado. São dois hoje: **Google Calendar** (no `plugin-agenda`) e **Stripe** (no `plugin-courses`). O card linka a ficha do plugin que o hospeda.
- **Catálogo da plataforma** — o provedor está habilitado no catálogo (o control plane existe), mas o conector é resolvido **no app** pela spine de conectores, não empacotado num plugin do SDK.
- **Roadmap** — catalogado, ainda não habilitado. Alguns marcados como *chegando* já têm ações declaradas no registro de capacidades do agente.

{% callout type="info" %}
Nada aqui é inventado: o catálogo vem do seed de conectores da plataforma e as ferramentas de agente vêm do registro de capacidades. Se um provedor aparece como *roadmap*, é porque ainda não tem conector plugável — e a página não finge o contrário.
{% /callout %}

## O catálogo

{% integrations-grid /%}

## Os dois planos

Toda integração real se apoia na **espinha de conectores** de `@fayz-ai/core` (`packages/core/src/integrations`), que separa a conexão em dois planos — o mesmo modelo descrito em [Conectores e canais](/pt-BR/docs/ia/conectores-e-canais):

- **Control plane** — a UI de `/settings`: conectar, testar a credencial (`testConnection`), escolher o que sincronizar. Um **ConnectorsHub** compartilhado na shell gerencia os provedores.
- **Data plane** — a **Supabase Edge Function** que roda o `sync` de verdade. O trabalho pesado fica no backend, nunca no navegador.

O contrato `Connector` / `ConnectorDefinition` costura os dois: declara o modo de autenticação (`oauth`, `api-key`, `mtls`), as capacidades que sabe sincronizar e as funções `testConnection` e `sync`.

## O seam `connectors` do manifesto

Um plugin publica conectores pelo campo **`connectors`** do [manifesto do plugin](/pt-BR/docs/referencia/plugin-manifest) — é assim que o plugin vira um addon de um host e passa a oferecer um provedor externo. Os dois conectores que já existem seguem exatamente esse caminho:

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

Um plugin próprio (ou um plugin de incubator) replica esse `ConnectorDefinition` para falar com qualquer provedor do catálogo. Veja o padrão de conector client-side (ex.: PlugBank/open banking) na página [Incubator](/pt-BR/docs/plugins-proprios/incubator).

---

Veja também: [Conectores e canais](/pt-BR/docs/ia/conectores-e-canais) para o fluxo de canais de mensagem (WhatsApp é roadmap), o campo `connectors` no [Manifesto do plugin](/pt-BR/docs/referencia/plugin-manifest) e o [Catálogo de plugins](/pt-BR/docs/plugins).