Allow dynamic credential selection at execution time, or allow native Google nodes (Gmail / Google Calendar) to accept externally-issued OAuth tokens (access + refresh) instead of requiring a statically selected n8n credential.
My use case:
I’ve built for clients multiple multi-tenant SaaS where AI agents CRUD Gmail and Google Calendar on behalf of end users.
OAuth is handled outside n8n (via Clerk), so for each execution I already have:
access_token
refresh_token
expiry info
any other info needed
However, n8n’s Gmail / Google Calendar nodes require a credential selected at design time, which makes them unusable in this setup.
As a result, I’m forced to:
Duplicate logic that native nodes already handle better
This comes up repeatedly across different projects.
I think it would be beneficial to add this because:
This is a hard blocker for SaaS / multi-tenant architectures
Native nodes become effectively single-tenant
Workarounds are:
brittle
time-consuming
less secure if users try to hack around credential storage
Other automation platforms explicitly support “run with user token” patterns
Supporting dynamic credentials would:
unlock serious SaaS use cases
reduce HTTP-node spaghetti
encourage best practices instead of hacks
significantly improve reusability of workflows
Any resources to support this?
Loads of conversation around this on the forum
Are you willing to work on this?
Yeah, not sure if I have the qualification, but with some help, I can try to start the work on it. Although this seems like a critical component so I’m pretty sure it needs a senior/principal dev on it.
This is a real game changer for multi-tenant SaaS: being able to inject dynamic OAuth tokens into Google nodes simplifies everything, no more hacky HTTP workarounds. It would be a huge leap in scalability and reliability, but it requires a senior dev to do it right.