# Connectors and channels

If the [data layer](/en/docs/ai/your-app-as-a-data-layer) is about what an AI can read and do **inside** your app, this page is about the **bridges outward**: syncing with external providers (Google Calendar, Stripe) and — the question founders ask most — serving customers over messaging channels like WhatsApp.

Part of this is already in production. Part of it is roadmap, and we say plainly which is which. For the full list of providers in the catalog (with each one's status), see the [Integrations](/en/docs/plugins/integrations) page.

## The connector spine

There's a real connector contract in `@fayz-ai/core` (`packages/core/src/integrations`): `Connector` and `ConnectorDefinition`. A connector declares:

- **An auth mode** — `oauth`, `api-key` or `mtls`.
- **Capabilities** — what it knows how to sync.
- **`testConnection` and `sync`** — test the credential and pull/push data.

A plugin publishes connectors through the manifest's `connectors` field (the plugin becomes an addon of a host). The shell ships a shared **ConnectorsHub** in settings, where users connect and manage providers. The heavy sync work runs in **Supabase Edge Functions** — the data plane lives in the backend, not in the browser.

{% callout type="tip" %}
Think in two planes: the **control plane** is the `/settings` UI (connect, test, choose what to sync); the **data plane** is the edge function that actually performs the sync. The contract in `@fayz-ai/core` stitches the two together.
{% /callout %}

## Two connectors that already exist

This isn't theory — two POCs have shipped:

{% cards %}
{% card title="Google Calendar" icon="📅" %}
In `plugin-agenda`: OAuth, a calendar picker and event sync. It lives in `src/integrations/google-calendar`. It's the canonical example of a plugin-native connector.
{% /card %}
{% card title="Stripe" icon="💳" %}
In `plugin-courses`: a payments connector in `src/connectors/stripe.ts`. It shows the same contract applied to a billing provider.
{% /card %}
{% /cards %}

Both follow the same `ConnectorDefinition` — it's the pattern your own plugin replicates to talk to any external provider.

## Messaging channels — and WhatsApp

Here's the part founders press on: **how these products reach WhatsApp**. The honest answer has two halves — the foundation that exists and the milestone still to come.

### What exists: the omni-channel inbox

`plugin-conversations` is an **experimental omni-channel inbox**. The channel enum already includes `whatsapp` as a label, and the plugin declares the `aiTools` `listConversations` (`read`) and `sendMessage` (`persist`). In other words: the **structure** for an inbox, threads and AI tools to read and reply is **already modeled**.

{% badge status="experimental" %}

What **doesn't** exist yet: the provider is a **mock**. There's no real messaging integration. No WhatsApp message goes in or out today.

### What's coming: real channel connectors

The plugin-conversations README states the next milestone without hedging:

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

{% callout type="warn" %}
**WhatsApp is roadmap.** There is no real WhatsApp, Twilio or Meta configuration in the SDK yet. Any screen suggesting otherwise would be lying. What exists is the experimental (mock) inbox and a connector contract ready to receive those providers.
{% /callout %}

### The target flow: AI-powered support on WhatsApp

When channel connectors land, the foundation is already designed for this — add the two halves of this section together:

```
WhatsApp Cloud API  ──▶  channel connector  ──▶  plugin-conversations (inbox)
                                                          │
                                      aiTools (listConversations, sendMessage)
                                                          │
                                                 your endpoint + LLM
                                                          │
                                        replies on WhatsApp with real
                                        tenant context (agenda, orders…)
```

The inbox receives the message through a real connector; the conversations `aiTools` (plus those of the other plugins) give the agent what to read and do; your endpoint runs the LLM; the reply goes back over the same channel. **Inbox + aiTools = AI-powered support on WhatsApp** — that's the architecture, and what's missing is the channel connector, not the rest.

## MCP: coming soon

A dedicated Fayz **MCP server** — so the agent can query the catalog and the docs without pasting URLs — is in design (docs only for now). Until then, the official path is [`llms.txt` and the `.md` pages](/en/docs/ai/connect-your-agent).

---

See also: [Your app as a data layer](/en/docs/ai/your-app-as-a-data-layer) and the `connectors` field in the [Plugin manifest](/en/docs/reference/plugin-manifest).