How to Add SaaS Integrations Without Building OAuth Yourself

On this page

1. What "building OAuth" actually involves
2. Separating authorization from integration logic
3. The options
4. What it looks like with managed OAuth
5. Questions to ask before choosing
6. Where Pathfix fits
7. Frequently asked questions

Your customers want your product to work with the tools they already use. To build those integrations, your application needs permission to access each customer's account in those tools, and for most modern APIs that permission comes through OAuth.

You can implement OAuth yourself for every provider. Many teams do. But the authorization layer is a different problem from the integration itself, and it's possible to build integrations without owning it.

What "building OAuth" actually involves#

For each provider, a full OAuth implementation includes:

1. Registering an OAuth app and configuring redirect URIs, scopes and consent screens.
2. Building the authorization request with state and PKCE.
3. Handling the callback and exchanging the code for tokens.
4. Storing tokens securely and associating them with the right customer.
5. Refreshing tokens, handling rotation and preventing concurrent refreshes.
6. Detecting revoked access and guiding users to reconnect.
7. Revoking and deleting tokens on disconnect.

Then repeat for the next provider, with different endpoints and rules.

Only step 1 really needs to be yours, because it creates the provider relationship and determines what customers see on the consent screen. Steps 2 to 7 are infrastructure.

Separating authorization from integration logic#

An integration has two layers:

• Authorization: getting and keeping permission to call the provider's API for this customer.
• Integration logic: deciding which API calls to make, transforming responses, and presenting the result in your product.

The second layer is where your product's value is. It's specific to your use case. The first is broadly the same for everyone.

When you use managed OAuth infrastructure, the authorization layer is handled for you. Your application still makes the API calls and owns the logic.

The options#

Managed OAuth infrastructure#

A service handles the flow, token storage and refresh, and lets you call providers' own APIs with the customer's credentials applied. You keep full control over which endpoints you call.

Best when: you need several integrations, want to work directly with provider APIs, and don't want to run token infrastructure.

Unified APIs#

A service normalizes several providers in a category into one data model and API. Authorization is usually included.

Best when: you need common data across many providers in one category and the normalized model covers your fields. Check carefully for operations or fields outside the model.

Embedded integration platforms#

Platforms that run workflows on behalf of each customer, often with prebuilt connectors.

Best when: integrations are multi-step workflows and event-driven processes.

Third-party automation tools#

Point customers to tools like Zapier to connect your product to others.

Best when: you want broad coverage quickly and customers are comfortable configuring automations themselves. The integration happens outside your product.

What it looks like with managed OAuth#

1. Register an OAuth app with the provider and add the credentials to the managed service.
2. Add a "Connect" button that starts the authorization flow.
3. The service stores and refreshes the customer's tokens.
4. Your backend calls the provider's API through the service, specifying which customer's connection to use.
5. Your code processes the response and updates your product.

Questions to ask before choosing#

• Do I need the provider's full API, or a common subset? Full API points to managed OAuth; common subset may suit a unified API.
• Will customers see my brand on consent screens? That depends on whether you can use your own OAuth apps.
• What happens when a connection breaks? How will you know, and how will the customer reconnect?
• Can I switch later? Owning your OAuth app registrations makes this easier.

Where Pathfix fits#

Pathfix OAuth is managed OAuth infrastructure. It handles the authorization flow, token storage, refresh and authenticated API passthrough across 350+ providers, using your own OAuth apps and credentials. Your application calls each provider's own API through Pathfix. Pathfix is not a unified API and doesn't supply prebuilt actions, so you build exactly the integration you need.

Browse supported providers or read the documentation.

Frequently asked questions#

Do I still need to register OAuth apps?#

With Pathfix OAuth, yes. You use your own OAuth apps and credentials, which keeps your brand on consent screens and the provider relationship with you.

Do I still need to know the provider's API?#

Yes. Managed OAuth handles authorization; you still choose and call the endpoints.

Can I mix approaches?#

Yes. Some teams use managed OAuth for most providers and a unified API or a native implementation where it makes sense.