Stop Writing OAuth Flows From Scratch: Meet Nango

If you've ever built an integration that needs to talk to a third-party API—like Google Calendar, Slack, or HubSpot—you know the pain. First, you wrestle with OAuth. Then you set up token refresh logic. Then you discover rate limits and handle retry logic. It's not hard, but it's tedious, error-prone, and it's the same damn thing every time.

That's where Nango comes in. It's an open-source framework that handles all that boilerplate for you. You get a unified OAuth flow, automatic token refresh, and built-in rate limiting and retry handling. The idea is simple: stop writing the same integration plumbing, and focus on the actual logic that matters to your users.

What It Does

Nango is a self-hostable service that acts as a middleware between your app and third-party APIs. You define which APIs you want to integrate, and Nango manages the OAuth handshake, stores and refreshes tokens, and handles rate limiting with exponential backoff.

Under the hood, it's a Node.js server with a Postgres database. You install it, configure it with your API providers, and then use its REST API or SDK to trigger actions. It supports dozens of providers out of the box—Google, Slack, GitHub, Salesforce, you name it. You can also add custom providers if yours isn't listed.

Why It's Cool

The most obvious win is saving time. Instead of writing a custom OAuth flow for each provider, you configure a single YAML file. But there are a few deeper reasons this stands out:

• It's open source and self-hosted. You control your tokens and your data. No third-party SaaS that could leak your users' access tokens. If you're building a B2B product, this is a must.

• Unified authorization model. You get a consistent API for connecting any provider. Your frontend just calls one Nango endpoint, and your backend gets a standard token object with user ID and provider info. No more mapping between different token formats.

• Automatic token refresh. Many OAuth tokens expire after an hour. Nango handles the refresh cycle transparently. Your code never sees a stale token.

• Rate limit handling. You define rate limits per provider, and Nango queues requests, retries with backoff, and returns errors in a predictable format. No more scattered 429 Too Many Requests handling across your codebase.

How to Try It

Getting started is straightforward. You'll need Node.js 14+ and Postgres.

# Clone the repo
git clone https://github.com/NangoHQ/nango.git
cd nango

# Install dependencies
npm install

# Configure your .env file with database URL and a secret
cp .env.example .env
# Edit .env with your Postgres connection string

# Run the server
npm start

Then add a provider in nango-config.yaml:

providers:
  - provider: google
    client_id: "your-client-id"
    client_secret: "your-client-secret"
    scopes: ["https://www.googleapis.com/auth/calendar"]

Your frontend can now redirect users to http://localhost:3000/oauth/connect/google and get back a token. For more detailed instructions, check the README or the docs.

Final Thoughts

Nango isn't going to replace a full-blown integration platform like Zapier or Paragon. But if you're building a product that needs to connect to a handful of APIs yourself, it's a solid time-saver. The self-hosted nature means you're not locked into a vendor, and the architecture is simple enough to debug if something goes wrong.

I'd use it for any internal tool or B2B product where security or control matters. The only downside is that you're still responsible for the actual API calls and data mapping—Nango just handles the auth and rate limiting. But honestly, that's the tedious part. Give it a shot.

—

Follow @githubprojects for more developer tools and open source highlights.