Generic OAuth2 in n8n: connecting an API with no native node

n8n covers several hundred integrations with a native node, but the web exposes tens of thousands of APIs — and yours doesn't always have its own dedicated node. Good news: the lack of a native node doesn't block anything as long as the API supports a standard authentication scheme. The HTTP Request node, combined with a generic OAuth2 API credential, lets you connect to any service exposing that protocol, with the same reliability as an official node. This guide covers the three OAuth2 flows available in n8n, how to configure them step by step, and the pitfalls that waste the most time the first time around.

When a generic OAuth2 credential replaces a native node

A native n8n node (Slack, HubSpot, Notion...) is nothing more than a wrapper: it pre-configures the provider's OAuth2 URLs and API endpoints so you don't have to look them up. Nothing stops you from reproducing that exact mechanism by hand for an API that doesn't have that wrapper — a business CRM, an internal ERP, a niche SaaS API, or your own company backend. The two ingredients you need: the provider documents its OAuth2 endpoints (Authorization URL, Access Token URL), and the HTTP Request node knows how to call your endpoints afterward — which it does natively, including pagination and retries on timeout on the calls that follow authentication.

The three grant types available in n8n

The generic "OAuth2 API" credential offers a Grant Type selector with three options, each suited to a specific scenario:

• Authorization Code — the most common flow for connecting a user's own account: a human is redirected to the provider's consent screen, grants access, and n8n then receives an authorization code it exchanges for an access token and a refresh token. This is what native Google, Slack, or HubSpot nodes do under the hood.
• Client Credentials — no user, no consent screen: the application authenticates directly with its Client ID and Client Secret to obtain a token representing the application itself, not a person. It's the simplest flow to set up, and the right choice for an internal API, an ERP, or a server-to-server B2B integration.
• PKCE (Proof Key for Code Exchange) — a hardened variant of Authorization Code, where n8n generates a temporary secret (code verifier) checked at token exchange, without exposing a fixed Client Secret. Some APIs require it for applications that can't reliably keep a confidential secret.

If you're unsure which one to pick, the target API's documentation usually settles it in one sentence: "server-to-server" or "machine-to-machine" points to Client Credentials; "connect your account" or a consent screen in their screenshots points to Authorization Code (or PKCE if explicitly mentioned).

Configuring the credential step by step (Authorization Code)

1. Create a new credential and search for OAuth2 API (the generic category, not tied to a specific service), then choose Grant Type: Authorization Code.
2. Fill in the Authorization URL and Access Token URL from the API's documentation (often under /oauth/authorize and /oauth/token), along with the Client ID and Client Secret generated on the provider's side.
3. Fill in the required Scopes, space-separated — request only what your workflows actually need, never the full list out of convenience.
4. Choose the Authentication Type: Header (Client ID/Secret sent as Basic Auth in the header, the most common) or Body (sent in the token request body) — the API's documentation states which one it expects.
5. Copy the OAuth Redirect URL shown at the bottom of the form, and paste it into your application's configuration on the provider's side (a "Redirect URI" or "Callback URL" field). Without this step, the provider refuses to redirect back to n8n after consent.
6. Click Connect my account: a window opens to the provider's consent screen; once approved, n8n automatically retrieves the access token and refresh token.

On a self-hosted instance, the OAuth Redirect URL depends directly on N8N_HOST and WEBHOOK_URL: if these variables don't point to your public HTTPS domain, the redirect fails before it even reaches the consent screen. That's the most common reason an Authorization Code flow never completes on self-hosted.

Client Credentials: the simplest flow for an internal or B2B API

For an API that doesn't represent a user but your application itself, Client Credentials removes two steps: no Authorization URL to fill in, no consent screen to approve in a browser. Choose this Grant Type, fill in only the Access Token URL, the Client ID, and the Client Secret (plus scopes if the API requires them), then click Connect my account: n8n calls the Access Token URL directly with your credentials and retrieves the token, with no redirect involved.

This is the flow to prefer whenever it's available: less surface for error, no dependency on a user who has to re-validate access if their account changes, and a token renewal that's fully automatic and silent.

Wiring the credential into the HTTP Request node

Once the credential is created, head to the HTTP Request node that will actually call the API:

1. In the Authentication tab, select Generic Credential Type.
2. Choose OAuth2 API as the type, then your credential from the list.
3. Configure the URL, method, and headers of the request just like any regular HTTP Request call — n8n automatically adds the OAuth2 token to the Authorization header, and renews it on its own via the refresh token when it expires (for Authorization Code) or by requesting a new token (for Client Credentials).

The same Generic Credential Type selector also offers Basic Auth, Header Auth, Query Auth, Digest Auth, and OAuth1 for APIs that don't require OAuth2 — no need to complicate a simple API key with an OAuth2 flow when Header Auth will do.

Common pitfalls that waste time

• Non-HTTPS callback URL on self-hosted: most OAuth2 providers reject a Redirect URL over http:// — make sure your instance is exposed over HTTPS before setting up Authorization Code, see our guide on HTTPS with Traefik or Caddy if that isn't already done.
• Scope added after the fact: changing the Scope field on an already-connected credential isn't enough — you need to click Connect my account again. An already-issued token can't be retroactively widened.
• PKCE forgotten when the API requires it: a vague error (invalid_request or code_challenge required) on the code exchange often signals you should have picked PKCE instead of Authorization Code.
• Authentication Type Header vs Body swapped: an invalid_client error is often caused by this setting rather than a wrong Client ID or Secret — the first thing to check before needlessly regenerating credentials.
• Refresh token silently expiring: a generic credential can end up with a refresh token revoked on the provider's side, causing an invalid_grant error on every workflow that depends on it — our guide on monitoring OAuth token expiry applies just as well here.

Security: one more API means one more secret to protect

Adding a generic OAuth2 credential gives n8n the ability to act on your behalf against an external system. A landmark study by Sun and Beznosov, presented at ACM CCS 2012 (The Devil is in the (Implementation) Details: An Empirical Analysis of OAuth SSO Systems, cited over 900 times), shows that most security flaws found in real-world OAuth deployments don't come from the protocol itself but from implementation mistakes: overly broad scopes, insufficient verification of the state parameter, confusion between a token's roles. The protocol is sound; it's the configuration that doesn't forgive mistakes.

Three habits limit the risk with a generic credential: request the narrowest scope possible for each use case rather than the broadest "just in case" — a leaked read-only token is far less damaging than one with full write access; never duplicate a Client Secret hardcoded into a Code node, always go through the credential, the same principle covered in securing n8n credentials in general; and document every generic credential you create (what it's for, which workflow depends on it), as detailed in our guide to managing credentials via the n8n API for anyone provisioning multiple instances.

Generic OAuth2 vs. API key: which one to choose

Criterion	Generic OAuth2	Simple API key (Header/Query Auth)
Setup complexity	Higher (URLs, scopes, redirect)	Minimal (paste the key)
Represents a specific user	Yes (Authorization Code)	No
Secret renewal	Automatic (refresh token)	Manual, on revocation
Permission granularity	Fine-grained (scopes)	Often all-or-nothing
Required by the target API	When the API only offers this	When the API offers it as an alternative

If the target API offers both, a static API key via Header Auth remains simpler to operate for a low-stakes internal use case; reserve generic OAuth2 for cases where the API requires it, where multiple users need to connect their own account, or where scope granularity genuinely matters.

Going further

This generic OAuth2 mechanism is exactly what lets you extend a RAG pipeline beyond Notion or Google Drive: any company document API that exposes OAuth2 can feed the same ingestion and vectorization chain, without waiting for a native node to exist. For a use case where the audit trail matters — knowing who connected which credential and when — the Compliance & Audit Pack logs this kind of event in Supabase beyond what n8n natively retains.

The bottom line

A missing native node should never be a wall: n8n's HTTP Request node and generic OAuth2 API credential cover Authorization Code, Client Credentials, and PKCE with the same reliability as an official integration. It comes down to a handful of well-understood settings — the right Redirect URL over HTTPS, the Authentication Type matching what the API expects, scopes as narrow as possible — plus the same credential hygiene you'd apply to any other sensitive secret on your instance.