Hello n8n team and community,
I would like to submit a feature request regarding OAuth user consent management via API.
Problem
Currently, OAuth consent flows in n8n can only be handled through the user interface. There is no API endpoint to:
-
initiate an OAuth consent flow,
-
check whether consent has already been granted,
-
associate OAuth consent with a specific workflow, user, or application context programmatically.
This UI-only approach becomes a blocker for fully automated setups.
Use case
We are using n8n in automated and multi-tenant SaaS environments, where:
-
users are onboarded dynamically,
-
integrations with third-party services are created on demand,
-
manual UI interaction is not feasible or scalable,
-
OAuth consent needs to be tightly controlled and auditable.
In such environments, relying on manual UI-based OAuth provisioning breaks automation and complicates security and lifecycle management.
Why this matters
An API-based OAuth consent capability would:
-
enable fully automated onboarding flows,
-
improve scalability for SaaS and enterprise deployments,
-
allow better security controls (explicit consent binding, lifecycle management),
-
align n8n with common OAuth practices used in modern automation platforms.
Without this, some advanced use cases require workarounds or custom implementations outside of n8n, which reduces its value as an automation backbone.
Expected behavior (high-level)
Ideally, n8n could expose API capabilities such as:
-
initiating an OAuth authorization flow programmatically,
-
querying consent status for a given credential or context,
-
safely binding consent to a workflow, tenant, or user scope.
Even a limited or controlled API (e.g. admin-only, self-hosted) would already be very helpful.
Closing
I understand this feature is not currently on the roadmap, but I wanted to share this request to give visibility to a real-world blocker for automation-heavy and multi-tenant use cases.
Thank you for considering this request. I’d be happy to provide more technical details or clarify the use case if needed.
Best regards,
Frédéric