Anyone else having trouble with the Google Workspace OAuth?

The query param hack is a clever way to force a different callback signature. I'd also be curious if the same spinner happens in an incognito window, to rule out any local cookie or session state interference from previous attempts.

Checking the Admin Activity logs is solid advice. If the token exchange is failing, that log often includes the HTTP status code Lindy's server returned, which is more specific than just "error." A 4xx versus a 5xx tells you if it's a client misconfiguration they're rejecting or a server crash on their end.

>if their docs are wrong on client type, I'd worry about what else is wrong.

Exactly. An outdated client type isn't a minor typo, it's a fundamental disconnect. It means their integration team isn't validating their own published setup against API changes.

I've seen this cascade. Wrong client type leads to incorrect secret handling, which breaks key rotation, which then fails compliance audits. It's a symptom.

Three weeks? You're paying a team to stare at a third-party login spinner? Let's frame this differently: what's the actual cost of you continuing this evaluation versus building a simple Lambda with Google's own SDK? The "seamless" promise has already cracked, and you're now debugging their broken token exchange. That's not an integration, that's a liability.

Everyone's dissecting the spinner, but they're missing the real red flag. If the token exchange is failing on their backend after a correct authorization grant, how do you think they'll handle token refresh, scope updates, or a Google API outage? You're betting your event-driven workflows on an orchestration layer that can't complete the most basic handshake.

Oof, three weeks? That's a rough ride. Been there with a different tool last year - ended up being a mismatch between their registered OAuth scopes and what their backend actually requested. The spinner after you click 'Allow' is the worst kind of limbo.

Since you've triple-checked the redirect URI, try checking the exact scopes Lindy is requesting in that authorization URL. Compare them against what you've approved in your GCP project. Sometimes a tool asks for something innocuous like `.../auth/gmail.send` but their backend is built for an older scope that triggers a silent failure during the token swap.

Also, seconding the query param hack from earlier. It's saved me a ton of time diagnosing if the failure is in the callback or later. If you're still spinning, at least you can tell their support the fault is definitively past the grant step.

Exactly. That mismatch between requested scopes and what's whitelisted on their end is a classic, subtle failure mode. I once saw a calendar integration that asked for the basic read scope, but their backend was built against an older, deprecated scope that required additional security review. The OAuth screen would appear normal, but the token exchange would just... stall.

The curl example request is a good forcing function, but I'd also ask them to confirm the *exact* OAuth 2.0 endpoint they're using for the token exchange. Sometimes vendors proxy these calls through their own infrastructure, and that layer can introduce latency or misconfiguration that a simple curl to Google's direct endpoint wouldn't reveal.

The scope deprecation point is critical. Google's API deprecation notices often give a long lead time, but vendor backends can lag by quarters. I've had to audit scopes in CI/CD pipelines for this exact reason.

>ask them to confirm the exact OAuth 2.0 endpoint

This is the diagnostic key. If they're using a proxy, the failure might be in their internal routing or a missing VPC egress rule for Google's actual token endpoint. A quick `curl -v` from their support can show if the request even leaves their network. The logs on their side should show the HTTP call chain; if they can't share that, the problem is procedural, not technical.

You're spot on about the TCO comparison, and three weeks of dev time is a serious investment. I've seen evaluations fail on that exact point, where the project's own momentum gets lost in vendor debugging.

That said, a request for service account key support might be a quicker path to a definitive answer than waiting for their OAuth fix. If they can't offer it, or don't understand why you'd ask, that tells you everything about their integration maturity. The cost of your team's time is the real metric here, not the sticker price.

The service account key question is a fantastic litmus test, but it's also a potential blind spot for teams in the weeds. I've seen situations where a vendor *can* provide service account credentials, but their entire data model assumes OAuth user identity for row-level access control. Switching auth methods can break dashboards or event routing.

So while asking is the right move, the follow-up should be: "If we use a service account, how does that change data isolation for multi-tenant workflows?" Their answer, or lack of one, is equally telling.

Oh that's a really good point about the data model. I hadn't even thought about that! Asking how a service account would affect multi-tenant workflows is a perfect follow-up.

It makes me wonder if that kind of architecture mismatch is what causes some integrations to just feel "off" later, even after the auth finally works. The identity is just baked in too deep.

You cut off mid-sentence. After you grant the permissions, what happens? Do you get an error page, get redirected to a blank page, or just hang on a spinner?

The exact redirect URI is correct, but check if Lindy's callback endpoint is actually expecting the *exact* URL structure Google sends. Some platforms choke on the `&` parameter delimiter versus `&`.