# Integrations

Fayz has an **integrations catalog** — external providers an app can connect to: databases, payment gateways, calendars, messaging channels, analytics and AI models. This page lists the catalog straight from the platform's source of truth and says, without dressing it up, **what actually has a real connector in the SDK today** versus what's catalog/roadmap.

The distinction matters: an item in the catalog does **not** mean there's a ready-to-plug connector. It means the provider is mapped and the connection path is designed. The badges on each card tell the truth.

## How to read the statuses

- **Connector in the SDK** — a real `ConnectorDefinition` exists, hosted inside a published plugin. There are two today: **Google Calendar** (in `plugin-agenda`) and **Stripe** (in `plugin-courses`). The card links to the specs of the plugin hosting it.
- **Platform catalog** — the provider is enabled in the catalog (the control plane exists), but the connector is resolved **in the app** by the connector spine, not packaged inside an SDK plugin.
- **Roadmap** — catalogued, not yet enabled. Some marked *coming soon* already have actions declared in the agent capability registry.

{% callout type="info" %}
Nothing here is invented: the catalog comes from the platform's connector seed and the agent tools come from the capability registry. If a provider shows up as *roadmap*, it's because there's no pluggable connector yet — and the page doesn't pretend otherwise.
{% /callout %}

## The catalog

{% integrations-grid /%}

## The two planes

Every real integration rests on the **connector spine** in `@fayz-ai/core` (`packages/core/src/integrations`), which splits the connection into two planes — the same model described in [Connectors and channels](/en/docs/ai/connectors-and-channels):

- **Control plane** — the `/settings` UI: connect, test the credential (`testConnection`), choose what to sync. A shared **ConnectorsHub** in the shell manages the providers.
- **Data plane** — the **Supabase Edge Function** that runs the actual `sync`. The heavy lifting stays in the backend, never in the browser.

The `Connector` / `ConnectorDefinition` contract stitches the two together: it declares the auth mode (`oauth`, `api-key`, `mtls`), the capabilities it knows how to sync, and the `testConnection` and `sync` functions.

## The manifest's `connectors` seam

A plugin publishes connectors through the **`connectors`** field of the [plugin manifest](/en/docs/reference/plugin-manifest) — that's how a plugin becomes an addon to a host and starts offering an external provider. The two connectors that exist today follow exactly this path:

{% cards %}
{% card title="Google Calendar → plugin-agenda" icon="📅" %}
OAuth, calendar picker and event sync in `src/integrations/google-calendar`. The canonical example of a plugin-native connector.
{% /card %}
{% card title="Stripe → plugin-courses" icon="💳" %}
Payments connector in `src/connectors/stripe.ts`. The same contract applied to a billing provider.
{% /card %}
{% /cards %}

Your own plugin (or an incubator plugin) replicates this `ConnectorDefinition` to talk to any provider in the catalog. See the client-side connector pattern (e.g. PlugBank/open banking) on the [Incubator](/en/docs/building-plugins/incubator) page.

---

See also: [Connectors and channels](/en/docs/ai/connectors-and-channels) for the messaging channel flow (WhatsApp is roadmap), the `connectors` field in the [Plugin manifest](/en/docs/reference/plugin-manifest), and the [Plugin catalog](/en/docs/plugins).