Hi Team-
We have n8n community edition embedded in our application. We call the n8n login API to invoke the login and then execute the workflow using webhook command.Intermittently we are getting the failure.
We also saw some of the recommendations related to following environment variables. But I could not find any official documentation for this:
N8N_RATE_LIMIT_LOGIN_MAX_ATTEMPTS or N8N_RATE_LIMIT_DISABLED
@rdangi 429 on /login is bruteforce protection, ur not supposed to hit /login per workflow trigger. for embedded use ur webhooks should fire straight without any login round-trip — login + webhook trigger are different things.
two cleaner paths:
webhook-only — hit the webhook URL directly. if u need auth on it, set the Webhook node Authentication field to Basic Auth / Header Auth / JWT and pass that on the request
need full API access (not just trigger) — use an API key from Settings → API instead of /login sessions. bearer token via X-N8N-API-KEY header, no rate limit on workflow triggers
webhook call looks like:
POST https://your-n8n/webhook/your-workflow-path
Content-Type: application/json
Authorization: Basic <base64 user:pass> (only if webhook node has basic auth on)
{ "your": "trigger payload" }
how are u chaining /login → webhook in ur code? if its per-request login thats whats hitting the limit
All of the above we are using the reverse proxy and utilizing the api key.
We also provide n8n authoring access for the end users without asking them to enter the credentials, so we login on behalf of the pre-created n8n member user. In this flow we utilize the /login call.
achamm :
What is the rate limit for /login call ? is this configurable ?
The “429” error you are seeing simply means that n8n is blocking your requests because you are calling the login API too frequently. It is a safety mechanism designed to stop hackers from trying thousands of passwords to break into an account.
Specifically, n8n limits login attempts to just 5 requests per minute for any single email address. Since your application logs in on behalf of your users every time a workflow needs to run, you are hitting this ceiling and getting blocked.
Regarding the environment variables you found online, they are not official. There are no supported settings to disable this specific login limit or increase the number of attempts because n8n considers this a critical security feature to prevent brute-force attacks.
To fix this, you should stop calling the login API for every single request. Instead, log in once, save the session token your application receives, and reuse that same token for all future calls until it expires. This will stop the 429 errors and make your application run much faster.
There is no “magic switch” or Enterprise license setting that simply turns off the login rate limit, as this is a hard-coded security feature to prevent hacking. Even with a paid license, the /login endpoint is strictly intended for humans typing in passwords, not for software making frequent automated calls.
The professional way to bypass this is to stop using the login API for your automated tasks. Instead, use API Keys. API keys are designed specifically for machine-to-machine communication; they are faster, more secure, and do not trigger the login rate limits because they don’t require a password check every time.
If you need your end-users to have authoring access without entering passwords, the Enterprise-grade solution is to set up SSO (Single Sign-On). This allows n8n to trust your application’s own identity system, letting users slide right into the editor without ever hitting the n8n login screen or its associated limits.
For machine to machine communications we are using API Keys. But for n8n authoring only this solution is implemented. We can look into the earlier suggession to cache the session token.
The 429 on /login is brute-force protection, and the real issue is that an embedded app should not be calling /login per workflow trigger at all. Login sessions and workflow triggers are two different things.
For triggering workflows from your app, hit the webhook URL directly, no login round-trip. If you need it secured, set the Webhook node Authentication to Header Auth or Basic Auth and pass that on the request. If you need actual API access beyond triggering, use an API key from Settings, API and send it as the X-N8N-API-KEY header. Neither path is rate-limited the way /login is.
The intermittent part is the tell: you are only hitting the limit under load, which is exactly when you least want it failing. Moving off /login removes the limit entirely rather than tuning N8N_RATE_LIMIT_LOGIN_MAX_ATTEMPTS around it.