Hey Guys,
I started to raise the 429 error “too many request” and digging into the rabbit hole, I discovered that the native n8n Gmail node was doing to many api calls for my needs, so I forked It, well the AI does, and I developed my own node, specifically thinked to be used with a service account with domain wide delegation.
Oh, and I took the chance to improve things I was solving by doing workarounds, you can read about it in the readme.
For anyone interested, it’s here:
Nice work addressing the 429 rate-limit issue with DWD - this is a real pain point for anyone managing Gmail at scale with service accounts. One thing worth documenting in the readme: how the node handles per-user token refresh when processing multiple impersonated addresses in a single execution. That detail tends to come up quickly once people start using it in bulk workflows, since getting that wrong can cause the first address to succeed but subsequent ones to fail silently.
Hey thanks for the heads up. I forgot to mention that due to the recent changes in Gmail quota management from Google, it’s a good practice to put a wait between a send and another, more is documented here Usage limits | Google Calendar | Google for Developers
So my node is not the final solution, but it reduce the amount of api calls like 1/8 in the best case compared to the native Gmail node, which was definitely good before the new restrictions (still not fully clear to me, but from today tests, I did not get any 429 error).
BTW, what you mentioned about the token handling is in the readme at the bottom, if I well understood your point… let me know.
Talking about this:
Token caching
Access token is cached in-memory for 58 minutes (3500 seconds). Cache key: ${serviceAccountEmail}:${delegatedEmail}. All three nodes share the same cache.
Per-email API calls: 1 Gmail API call after the first oauth call of the hour.
The token caching section does cover it - the per-email cache key (${serviceAccountEmail}:${delegatedEmail}) means each impersonated address gets its own cached token, which is the right design for bulk use cases. The edge case I was thinking about is actually handled correctly here. Worth adding a note in the readme that users running loops over 50+ addresses for the first time should expect a slightly longer first run as each token is acquired and cached - after that it’s fast. That sets clearer expectations for people testing with large batches.