Subscribe

Get authentic content to your mailbox

Nango vs Pipedream: Authorisation in the Age of AI

0:00
ai

Authorising third-party apps is a persistent challenge for developers. Each service provider has its own quirks, and managing OAuth flows or API keys on behalf of users adds complexity to any system. Tools like Nango and Pipedream step in to handle this, abstracting the authorisation process so you can focus on building functionality. Both let you authorise on behalf of users, and they approach the problem similarly, but some differences.

Nango is a newer, developer-centric player. It’s built for those who want control and flexibility, with a focus on integrating APIs into your app. Pipedream, on the other hand, has roots in workflow automation. It’s primarily UI-driven but offers developer options through code-based components. Last year, Pipedream introduced Pipedream Connect, which aligns more closely with Nango’s model of user authorisation. For this comparison, we’ll zoom in on Pipedream Connect rather than its broader workflow features.

How They Handle Authorisation

Both Nango and Pipedream Connect let you authorise third-party apps for your users. You start by setting up a provider (or “app” in Pipedream lingo) with a shared signing secret. The service handles the OAuth dance, generating a token tied to your user. Once authorised, you get a webhook response with the token, which you can store alongside your user_id in your database.

From there, both services let you use the token to act on behalf of the user. You can trigger actions directly or make proxy requests, where the service swaps your token for the provider’s OAuth bearer token behind the scenes. The flow is similar, but the execution diverges.

With Nango, when a token is created, users can be auto-subscribed to sync endpoints. Nango starts caching records—like new emails or CRM updates—and sends events to a single webhook (or two). You then fetch the data as needed. Pipedream takes a more manual approach. You create custom triggers for each user and app component, each tied to a unique webhook URL. Since the webhook payload doesn’t inherently identify the user, that unique URL becomes your way to map events back to the right person.

Terminology Breakdown

The two services use different labels for similar concepts:

  • Pipedream: App vs Nango: Provider – The third-party service you’re connecting to, like Gmail or Slack.
  • Pipedream: Source/Event Source/Trigger/App Trigger Event vs Nango: Sync – A specific event, like “new emails” or “new contact added”.
  • Pipedream: Components vs Nango: Endpoints – Pipedream’s components include triggers (events) and actions (tasks), while Nango splits these into syncs (data pulls) and actions (tasks like sending an email).

For example, “new emails” might be a trigger in Pipedream or a sync in Nango, while “send email” is an action in both.

OAuth Clients: A Key Difference

Pipedream Connect’s killer feature when starting out is letting you use its OAuth client application instead of registering your own. For services like Google, where setting up your own client involves videos and manual approval, this can save serious time. However, it’s not without trade-offs: users authorise “Pipedream” (e.g., “Pipedream would like to access your Salesforce account”), which can confuse them or raise flags in security reviews at larger companies. If you switch platforms later, users must re-authorise, and if the API provider revokes Pipedream’s access—say, over a policy dispute—your tokens stop working. Some APIs even ban this credential-sharing in their terms. Nango, by contrast, requires you to bring your own client for each provider. It’s more setup, but you keep full control, avoiding these risks and maintaining your branding throughout the auth flow.

Integration Coverage

Pipedream boasts over 2500 integrations out of the box, dwarfing Nango’s 400+. Beyond sheer numbers, Pipedream also supports a broader set of endpoints per integration, giving you more pre-built options to work with. In saying that both claim you can “instantly connect” to these services, but in practice, you’ll likely need to tweak each endpoint for your app—there’s no true plug-and-play. Nango shines when you want to add custom endpoints, offering a straightforward process that, with an LLM’s help, becomes almost trivial. Pipedream’s extensibility exists but leans heavier on its existing library, which might limit you if your needs fall outside its scope.

Code Examples

Here’s how you’d work with each service, keeping it concise where possible.

Nango

  • Authorise a Connection:

    import Nango from '@nangohq/frontend';
const nango = new Nango();
nango.openConnectUI({
  onEvent: (event) => {
    if (event.type === 'connect') console.log('Auth successful');
  }
});
const res = await fetch('/sessionToken', { method: 'POST' });
nango.setSessionToken(res.sessionToken);

  • Webhook Event Payload (Sync Event):

    {
  "connectionId": "user123",
  "providerConfigKey": "google",
  "syncName": "gmail-emails",
  "model": "Email",
  "responseResults": { "added": 5, "updated": 0, "deleted": 1 },
  "syncType": "INCREMENTAL",
  "modifiedAfter": "2025-03-26T10:00:00Z"
}

  • List Records:

    import { Nango } from '@nangohq/node';
const nango = new Nango({ secretKey: 'your-secret-key' });
const records = await nango.listRecords({
  providerConfigKey: 'google',
  connectionId: 'user123',
  model: 'Email',
  modifiedAfter: '2025-03-26T10:00:00Z'
});

  • Call an Action:

    import { Nango } from '@nangohq/node';
const nango = new Nango({ secretKey: 'your-secret-key' });
const result = await nango.triggerAction('google', 'user123', 'send-email', {
  to: 'friend@example.com',
  subject: 'Hi'
});

  • Proxy Request:

    const options = {
  method: 'GET',
  headers: {
    'Connection-Id': 'user123',
    'Provider-Config-Key': 'google'
  }
};
const response = await fetch('https://api.nango.dev/proxy/gmail/v1/users/me/messages', options);

Pipedream Connect

  • Authorise a Connection:

    import { createFrontendClient } from '@pipedream/sdk/browser';
const pd = createFrontendClient();
async function connectAccount(token) {
  pd.connectAccount({
    app: 'google',
    token, // From your server
    onSuccess: ({ id }) => console.log(`Connected: ${id}`)
  });
}
const { token } = await fetch('/connectToken', { method: 'POST', body: JSON.stringify({ external_user_id: 'user123' }) });
connectAccount(token);

  • Deploy a Trigger:

    import { createBackendClient } from '@pipedream/sdk/server';
const pd = createBackendClient({ credentials: { clientId: 'id', clientSecret: 'secret' }, projectId: 'proj123' });
const { data } = await pd.deployTrigger({
  triggerId: { key: 'google-new-email' },
  configuredProps: { google: { authProvisionId: 'apn_123' } },
  externalUserId: 'user123',
  webhookUrl: 'https://yourapp.com/webhook/user123'
});

  • Webhook Event Payload:

    {
  "steps": {
    "trigger": {
      "event": { "emailId": "abc123", "from": "someone@example.com" },
      "context": {
        "id": "evt_123",
        "ts": "2025-03-26T10:00:00Z",
        "deployment_id": "dep_456"
      }
    }
  }
}

  • Invoke an Action:

    import { createBackendClient } from '@pipedream/sdk/server';
const pd = createBackendClient({ credentials: { clientId: 'id', clientSecret: 'secret' }, projectId: 'proj123' });
const { exports } = await pd.runAction({
  actionId: { key: 'google-send-email' },
  configuredProps: { google: { authProvisionId: 'apn_123' } },
  externalUserId: 'user123',
  data: { to: 'friend@example.com', subject: 'Hi' }
});

  • Proxy Request:

    import { createBackendClient } from '@pipedream/sdk/server';
const pd = createBackendClient({ credentials: { clientId: 'id', clientSecret: 'secret' }, projectId: 'proj123' });
const resp = await pd.makeProxyRequest(
  { searchParams: { external_user_id: 'user123' } },
  { url: 'https://gmail.googleapis.com/gmail/v1/users/me/messages', method: 'GET' }
);

MCP and Introspection

The Model Context Protocol (MCP) is like a phonebook for large language models (LLMs). It standardises how AI agents discover what they can do and how to act on a user’s behalf. Both Nango and Pipedream are leaning into this as AI integration grows.

Pipedream recently launched mcp.pipedream.com, letting developers plug MCP API calls into their IDEs. They’re also planning to support MCP server calls on behalf of customers soon (according to their slack community support person). Triggers in Pipedream are configurable—think form-based triggers with custom payloads—but this flexibility can limit live system introspection. Their MCP servers solve this by predefining how components trigger actions.

Nango offers an introspection API (docs.nango.dev/reference/api/scripts/config) that serves a similar role. It details available endpoints and syncs, which can be adapted for MCP-like use by AI agents. Customisation in Nango happens via custom endpoints, and these definitions flow into the introspection API, giving a clear view of the system’s state.

Pipedream’s ahead on MCP adoption, with a more polished vision for AI workflows. Nango’s introspection is tighter, with precise typings and real-time system visibility, even if it’s less standardised.

Wrapping Up

Nango and Pipedream Connect tackle authorisation in distinct ways. Nango suits developers who want granular control and tight integration, with auto-syncs and a single webhook simplifying data flows. Pipedream Connect leans on its pre-built OAuth clients and custom triggers, ideal for those prioritising speed and flexibility over setup effort. As AI and MCP reshape how we interact with systems, Pipedream’s pushing the envelope, while Nango keeps it precise and developer-focused. Choose based on where your priorities lie—control or convenience.

Previous Post⇐ AI Model & Vendor Vibe Check: February 2025