> ## Documentation Index
> Fetch the complete documentation index at: https://pipedream.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# The Pipedream Connectors

> Thousands of app integrations with managed OAuth, configured once per workspace.

The Pipedream connector gives a workspace tools for thousands of SaaS apps —
Slack, Google Workspace, Notion, GitHub, and the rest of the
[Pipedream catalog](https://pipedream.com/apps) — with authentication to each
app managed by [Pipedream Connect](https://pipedream.com/docs/connect). Members connect their own accounts
through a consent flow; Pipedream stores those credentials in its vault and
executes each app's API; Conduit decides who may use which app and tool, and
records every call.

You can configure your Pipedream connection, per workspace, at the top of
**Settings → Connectors**.

## Setup

You need a Pipedream workspace with Connect and a project in it. From its API
settings, create **OAuth client credentials** — one pair per Conduit
workspace. Then enter into Conduit:

* **Client ID and secret** — the secret is write-only and stored encrypted,
  like every credential Conduit holds.
* **Project ID** and **environment** (development or production).

That's the whole registration — there is nothing else to register on the
Pipedream side. Saving runs a connectivity check and reports the result, and
distinguishes bad client credentials from a project the credentials can't
use.

Individual apps become available to members through
[access policies](/docs/conduit/configure/access-control): grant `Slack` to a group the way you'd
grant any connector, or grant all apps and let members enable what they need.
The policy editor searches the app catalog directly.

## How Conduit authenticates to Pipedream

Conduit exchanges the workspace's client credentials at Pipedream's token
endpoint for a short-lived, workspace-scoped access token, caches it, and
re-mints it as needed — the standard OAuth client-credentials grant. This
token authenticates Conduit itself (tool listing and calls, the app catalog,
account management); it is never handed to browsers or AI clients.

## How members connect their app accounts

Connecting an app account is a per-member action, from the **Connectors**
page — or [directly from their AI client](/docs/conduit/use/mcp-reference#connecting-your-accounts-from-the-client),
which guides the member to the same place:

1. Conduit mints a short-lived, single-use **Connect token** scoped to the
   member and hands it to the browser.
2. The browser opens Pipedream's connect flow, where the member authorizes
   the app on the app's own consent screen (standard OAuth between Pipedream
   and the app).
3. Pipedream stores the resulting credential in its vault, keyed to the
   member's Conduit identity. Conduit then verifies with Pipedream that the
   account actually exists — the browser's word is not trusted — and
   refreshes the member's tool lists.

App credentials therefore live in Pipedream's vault, not in Conduit's
database, and never pass through the AI client. Members see their connected
accounts — with health status — on the **Accounts** page and can disconnect
them there; disconnecting revokes the stored credential.

## How tool calls carry identity

When a member's client calls an app tool, Conduit forwards the call to
Pipedream's MCP endpoint with headers identifying the workspace's project and
environment, **the calling user**, and the apps the caller's policy resolution
permits. Pipedream uses the user identity to fetch that member's credential
from its vault — so every call executes as the person who made it, and one
member's Slack tools can never post as another's.

These headers are set by Conduit from workspace configuration and the
authenticated session, on every call. They cannot be overridden: connector
configuration rejects header names in the gateway-identity namespace, so
neither an admin nor a member can supply a different user or project by
configuration.

## Network path

Conduit reaches exactly two Pipedream hosts — the API (token minting, Connect
tokens, account management, the app catalog) and the MCP endpoint (tool
listing and calls) — and the member's browser loads the connect flow from
`pipedream.com`.

[Network Access](/docs/conduit/deploy/network#fixed-hosts) lists all of them precisely,
and the
[private-endpoints guide](/docs/conduit/deploy/network#example-pipedream-through-a-private-endpoint)
covers consuming both hosts over a private endpoint such as AWS PrivateLink —
supported at the application level with one environment variable.

## Observability

Pipedream app calls are first-class citizens of Conduit's governance: each
call is policy-checked before it leaves, recorded in usage dashboards under
its full tool name (a denied call also lands in the audit log), traced end to
end, and counted in the
per-connector metrics. Nothing about the managed-auth path bypasses the
gateway's controls.