> For the complete documentation index, see [llms.txt](https://docs.fastn.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.fastn.ai/build/connectors.md).

# Connectors

What a connector is, how it relates to actions, auth methods, connections and webhooks, and where each part lives in the app.

**Integrations → Connectors** · `/integrations?tab=connectors`

<figure><img src="https://1255842839-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F3iSr2Tx8FvvuoLPncziH%2Fuploads%2Fgit-blob-04d05d355abca4da4f041daad38ea6cbb4f52eae%2Fconnectors-catalogue.webp?alt=media" alt="The Connectors page: Import, Request connector and Create connector buttons top right, a Categories list on the left starting with All connectors 422, a search box with All, Connected and OAuth chips and an All Visibility filter, connector cards such as AbstractAPI Email Reputation badged managed with a Connect button, and the Connectors guide panel on the right"><figcaption><p>The Connectors catalogue with the guide panel open.</p></figcaption></figure>

A **connector** is fastn's bridge to one external app, such as HubSpot, Jira or Stripe. The page describes it in one line:

> A connector is fastn's bridge to one app: it handles sign-in and exposes the app's actions and events. Sign in to one to create a connection.

A connector is a **definition**. It holds no credentials. Credentials live on a [connection](/build/connections.md), which is created when someone signs in to the connector.

### The parts of a connector

| Part               | What it is                                                                                                                                                | Where you see it                                                                                   |
| ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
| **Actions**        | One operation the app can perform, such as *Create Contact* or *List Owners*. Each action is an HTTP request with an input schema and an output schema.   | The action list on the connector's detail page. See [Actions](/build/connectors/action-detail.md). |
| **Auth methods**   | How a customer proves who they are to the app: OAuth 2.0, API key, bearer token, basic auth and so on. A connector can offer several; one is the default. | The **Auth** tab. See [Auth methods and providers](/build/connectors/auth-methods.md).             |
| **Auth providers** | For OAuth methods, the OAuth app (client ID and secret) that fastn uses to send people to the app's consent screen.                                       | **Auth → View providers**.                                                                         |
| **Webhook config** | Instructions for subscribing to the app's events on behalf of each customer, so an [app event trigger](/build/triggers/app-events.md) can fire.           | The **Webhook config** tab. See [Webhook config](/build/connectors/webhook-config.md).             |
| **Versions**       | Every change to a connector produces a version. Versions live in **Test** until they are published to **Live**.                                           | **Overview → Versions**, and the **Version pins** tab.                                             |
| **Connections**    | Signed-in accounts that use this connector.                                                                                                               | The **Connections** tab, and the workspace-wide [Connections](/build/connections.md) page.         |

### Managed and custom connectors

Every card carries a badge that says who maintains it.

* **managed**: built and maintained by fastn. The card reads *Managed by Fastn*. You can view every part of it, connect to it, export its actions and run them, but you cannot edit, delete or publish it. To suggest a change to one of its actions, use **Propose an update**. Fastn reviews it, and vendor changes reach you as proposals under [Pending updates](/build/connector-updates.md).
* **Custom**: created in your workspace with **Create connector** or **Import**. Your workspace owns it, so you can edit it, add actions, set up its webhook config, publish versions and delete it.

When a connector has at least one connection, its badge changes to **Connected**.

### How the pieces work together

{% stepper %}
{% step %}

#### Pick or build a connector

Find the app in the [catalogue](/build/connectors/the-catalogue.md). If it is not there, [request it](/build/connectors/creating-a-connector.md#request-a-connector) or [create it](/build/connectors/creating-a-connector.md).
{% endstep %}

{% step %}

#### Connect

**Connect** opens a dialog that asks for the credential the default auth method needs (an API key, or an OAuth sign-in). The result is a connection. See [Connect a system](/build/connectors/connect-a-system.md).
{% endstep %}

{% step %}

#### Use the actions

Workflows, the Agent and the MCP gateway call the connector's actions through that connection. The connection decides whose account the call runs as.
{% endstep %}

{% step %}

#### Receive events (optional)

If the connector has a webhook config, fastn runs its subscription code for each new connection, so that events from that account reach fastn and an app event trigger can start a workflow.
{% endstep %}
{% endstepper %}

{% hint style="warning" %}
**Connect** on this page signs in *your own* account. Your customers sign in their own accounts through the widget you embed. The guide panel on the page says the same: *Connecting here signs in your account. Your customers sign in their own, through the widget.*
{% endhint %}

### In this section

* [The catalogue](/build/connectors/the-catalogue.md): searching, filtering and reading the connector cards.
* [Creating a connector](/build/connectors/creating-a-connector.md): the Create connector dialog, every protocol and auth type, and Request connector.
* [Inside a connector](/build/connectors/inside-a-connector.md): the detail page, its Overview, Connections and Version pins tabs, and versions.
* [Auth methods and providers](/build/connectors/auth-methods.md): the Auth tab and the OAuth apps behind it.
* [Actions](/build/connectors/action-detail.md): the action list and the action editor with its seven tabs.
* [Webhook config](/build/connectors/webhook-config.md): how fastn subscribes to an app's events.
* [Editing, publishing and deleting](/build/connectors/editing-and-deleting.md): what you can change on a connector your workspace owns.
* [Importing and exporting](/build/connectors/importing-and-exporting.md): moving connectors and actions in and out as JSON.
* [Connect a system](/build/connectors/connect-a-system.md): making a connection, step by step.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.fastn.ai/build/connectors.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
