Skip to main content
The Pipedream connector gives a workspace tools for thousands of SaaS apps — Slack, Google Workspace, Notion, GitHub, and the rest of the Pipedream catalog — with authentication to each app managed by Pipedream 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: 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, 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 lists all of them precisely, and the private-endpoints guide 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.