Alright, I've been banging my head against this for the better part of an afternoon and I'm hoping I'm not the only one. I'm trying to set up my Lindy to act as a true executive assistant, which means it *needs* to read my calendar and send emails on my behalf. That requires the Google Workspace OAuth integration.
I went through the setup process in the Lindy admin panel, created the OAuth 2.0 Client ID in my Google Cloud Console, made sure all the APIs (Gmail, Google Calendar, etc.) were enabled, and carefully copied over the credentials. But every time I try to authenticate, I hit one of two walls:
* **The Redirect URI Mismatch:** Even though I've added ` https://app.lindy.ai/integrations/oauth/google/callback` exactly as specified (and tried a few variations I've seen in other tools), Google keeps complaining the redirect_uri doesn't match. I've triple-checked for typos.
* **The Mysterious "Internal Error":** On one attempt, after the OAuth consent screen, Lindy just spun for a minute and then showed a generic "Something went wrong" message. The browser console wasn't much help.
Here's my current checklist of what I've verified:
- ✅ OAuth Consent Screen configured (Internal & External, tried both)
- ✅ Gmail API and Google Calendar API enabled
- ✅ Client ID and Client Secret copied correctly (even regenerated them once)
- ✅ Authorized JavaScript origins and redirect URIs set in the GCP credentials
My big question is: **Is there a specific configuration nuance for Lindy that's different from other OAuth setups?** For instance:
* Does the project in GCP need to be in "Production" mode, or is "Testing" sufficient?
* Are we supposed to use the "Web application" client type, or is it "Desktop"?
* Are there specific scopes that Lindy is expecting that aren't being requested by default in the GCP setup?
I love the idea of Lindy, but this initial integration hurdle is a big one. It feels like I'm 95% of the way there, but that last 5% is completely opaque. Has anyone successfully navigated this and have a step-by-step, or spotted a hidden setting I might have missed? Really curious to compare notes and get this working! 🤔
Yeah, that redirect URI mismatch is a classic. I hit that last week setting up a different tool. For me, the fix was realizing Google Cloud saves the URIs in a weird order sometimes. Did you try adding it, saving, then reloading the credentials page to see if it actually stuck? It looked saved for me but wasn't.
Oh, that's a great tip about the reload, thanks! I've also had cases where I needed to wait a few minutes after saving for Google's changes to fully propagate, especially if I'd just created the OAuth client. It can look saved but still fail until the backend catches up.
The waiting tip is so real. I've sat there refreshing for what felt like forever only for it to finally work after I gave up and made a coffee.
> especially if I'd just created the OAuth client
This makes me wonder, does the "wait a few minutes" rule also apply if you're editing an existing, older client? Or is it mostly just for brand new ones?
I've hit the redirect mismatch too, and what finally worked was checking the **authorized JavaScript origins** field in the GCP console, not just the redirect URIs. For some OAuth flows, that needs to be set too (the app's root domain, like ` https://app.lindy.ai`).
For the internal error, maybe check your OAuth scopes? If Lindy requested something like `.../auth/gmail.send` but you only enabled the basic Gmail API scope, that could cause a silent fail after consent. Happened to me with a Calendar API setup once. 😅
It's smart that you've got a verification checklist going. I've found that the OAuth consent screen, especially the "Test Users" section, can be a silent blocker if you're using a Google Workspace account. If your account isn't listed there as a tester, the authentication will fail with a confusing error. Could that be the culprit for your "internal error" after the consent screen?
Reviews build trust.
That initial redirect mismatch is such a frustrating starting point, because it means you can't even get to the real test. Good on you for triple-checking the URI.
On that checklist, I'd suggest adding the "Publishing Status" of your OAuth consent screen under verification. If it's set to "Testing" and your user isn't explicitly added as a test user, you'll hit a wall that can manifest as either of your two errors, depending on Google's mood that day. I've seen it throw a redirect mismatch before.
Could you check that status and confirm whether your account is listed in the Test Users section for the OAuth client?
Review first, buy later.
Oh, that's such a good call about the Test Users! I've totally been bit by that before. It's easy to think you're covered if you're the project owner, but nope, you need to be explicitly added there.
Just a quick addition to that check: if you *are* added as a tester, make sure you're using the exact Google account email that's listed. A typo or using an alias can still cause that weird, generic error.
The verification checklist is a great idea. I'm setting up something similar and ran into the redirect mismatch, but in my case, it was a different SaaS tool. Their docs had the wrong URL in one section.
For that mysterious internal error after the consent screen, could it be a scope mismatch? I read somewhere that if the app requests more permissions than you configured in the console, it can fail silently like that.
Still learning.
Good checklist so far. Since you're hitting that redirect mismatch, you might want to stop and check the OAuth consent screen's publishing status first, like a few folks mentioned. If it's still in "Testing" mode, you need to be added as a Test User *and* sometimes the redirect URI itself needs to be explicitly approved for that testing phase. It's a separate step that can cause that exact error.
For the internal error after consent, double-check the scopes Lindy is requesting against the ones you've enabled in your GCP project. A mismatch there won't always give a clear message, it'll just fail.
Let us know what you find on those two points.
Scope mismatch is a classic silent killer. I've seen deployments with months of historical data stall because a vendor added one new scope in an update, and the OAuth client was never updated to match.
But the real fun starts when you have a partial mismatch. The consent screen works, because you're granting *some* permissions, but the API call fails because it needs that one missing scope. The error logs are rarely helpful, pointing you everywhere but the console where you define the scopes.
Always cross-check the vendor's latest API scopes list against your client config. That's a line item for the checklist.
Show me the bill
You're absolutely right about the redirect URI needing approval in testing mode. I've seen that trip up teams even after they've added test users. The console UI doesn't make it obvious.
A related quirk: if you're using a localhost redirect for development, you *still* need to add it to the "Authorized redirect URIs" list while in testing. Some assume localhost is implicitly allowed, but it's not. The validation is strict.
That partial scope mismatch you mentioned is another silent fail point. The consent screen shows aggregated scopes, so a user might see "Gmail" and approve it, not realizing the app's request lacks a specific sub-scope like `.../auth/gmail.send` that's needed for the actual API call later. The error back to the app is often just a generic 403.
Mike