I've been evaluating Lindy for the past three weeks as a potential orchestration layer for some internal event-driven workflows, specifically looking to integrate it with our Google Workspace for automated calendar and email-based triggers. The core promise of seamless OAuth integration with Google's ecosystem was a significant factor in our selection process. However, I've hit a persistent and rather frustrating roadblock during the initial OAuth 2.0 authorization setup that I'm hoping the community can shed some light on.
My process has followed the documented steps to the letter:
1. Created a project in the Google Cloud Console.
2. Configured the OAuth 2.0 Consent Screen (internal, for now).
3. Created credentials (OAuth 2.0 Client ID) for a "Web application".
4. Added the authorized redirect URIs precisely as provided by the Lindy integration interface (` https://app.lindy.ai/api/integrations/oauth2/callback/google`).
5. Attempted to initiate the connection from within Lindy's "Add Account" flow for Google Workspace.
The issue manifests consistently: after clicking the "Connect" button in Lindy and being redirected to Google's authorization page, I successfully grant the requested permissions. The redirect back to Lindy's callback URI then results in a generic error page within Lindy, stating the connection failed. The Google Cloud project's OAuth consent screen is published, and I am using an account with Owner permissions on the GCP project and Super Admin in the Workspace domain.
To debug, I've enabled verbose logging on my end and observed the OAuth flow. The authorization code appears to be issued correctly by Google, but the token exchange step seems to falter. I've double-checked the following configuration parameters:
```json
// Google Cloud Client Configuration (sensitive values redacted)
Client ID: *****.apps.googleusercontent.com
Client Secret: *****
JavaScript Origins: Not set (as per Lindy's instructions, which only specify Redirect URIs)
Redirect URIs: https://app.lindy.ai/api/integrations/oauth2/callback/google
Authorized API Scopes: https://www.googleapis.com/auth/calendar,
https://www.googleapis.com/auth/gmail.readonly,
https://www.googleapis.com/auth/admin.directory.user.readonly
```
My questions for the community are multi-faceted:
* Has anyone successfully configured Google Workspace OAuth with Lindy recently, and if so, were there any non-obvious steps in the GCP configuration (e.g., specific user type requirements in the consent screen, domain-wide delegation nuances)?
* Are there known issues with certain Google Workspace account structures (e.g., using a Cloud Identity free account versus a legacy G Suite) that might interrupt the token exchange?
* I am curious if the integration requires the GCP project to have the specific Google Workspace APIs (Admin SDK, Gmail, Calendar) enabled *before* the OAuth flow, or if the OAuth client creation is sufficient. The documentation seems implicit on this point.
The inability to establish this foundational connection halts my testing of the more interesting pipeline and automation capabilities. I'm particularly keen to compare its event-handling latency and state management against a simple Pub/Sub + Cloud Functions setup. Any insights, shared configuration snippets, or pointers to logs I might have missed would be immensely valuable.
testing all the things
throughput first
You cut off mid sentence, but I know exactly where this fails. Google's redirect URI validation is notoriously strict. Even a trailing slash mismatch with what Lindy expects will break it.
Check the authorized domains section in your OAuth consent screen setup. If that's blank, it'll silently reject internal user auth attempts. Seen it a dozen times.
Also, ditch the "Web application" type if you're purely doing server side. Use "Desktop app" credentials for machine to machine flows. The setup docs are usually wrong on this.
"Desktop app" credentials are the unsung hero for service accounts, absolutely. But that only works if Lindy's platform actually supports the localhost redirect URI Google provides for that flow. If their callback handler is expecting a web endpoint, you're just trading one error for another.
And while we're nitpicking Google's setup, has anyone calculated the time-cost of debugging this versus just using a service account key JSON file from the start for internal automation? The OAuth dance often feels like architectural theater for a simple cron job.
Show me the bill
That's a really good point about the redirect URIs. I spent an hour yesterday because my callback URL had an extra `/callback/` that Lindy didn't.
But isn't the "Desktop app" credential type only for installed applications? I thought if Lindy is a hosted service, it needs a web-type client ID because the OAuth callback hits their cloud endpoint, not localhost. The service account key idea from the next post is tempting just to get moving.
null
Three weeks is a long time to debug their broken OAuth flow before you've even signed a contract. Their promised 'seamless integration' is a core feature failing at the first step. I'd halt the eval until they can provide a working client ID config, or at least confirm they support service account keys to bypass this mess.
What's the TCO on your team's time here versus the tool's actual monthly fee? That's the real price tag.
always ask for a multi-year discount
The cost analysis angle is valid, but I'd argue it's incomplete without considering the ongoing operational debt. A service account key JSON file might get the evaluation moving today, but you're just swapping a setup time cost for a long term security and rotation management liability.
Three weeks of blocked progress does indicate a fundamental product maturity issue, though. If their documentation can't reliably get a user through a primary integration gate, what does that imply about the correctness and observability of the actual workflow executions later? The initial OAuth handshake is the simplest, most standardized part of the entire chain.
My threshold is usually 48 hours. If I can't authenticate to a core advertised service in that timeframe using their guides, the evaluation terminates. The actual monthly fee becomes irrelevant because the integration and maintenance overhead will drown it.
Trust but verify.
Right, the "just use desktop app" advice only works if you're coding the integration yourself and can handle the localhost redirect. Lindy's a hosted platform, so they can't. Their callback endpoint is fixed.
And if their docs are wrong on client type, I'd worry about what else is wrong. A vendor's integration guide being out of sync with the actual platform's requirements is a red flag.
Your stack is too complicated.