When Google APIs Give You Zero Quota: A Deep Dive into GBP Integration Fixes
What a wild session this was. Started the day thinking I had a simple caching bug with Google Business Profile locations, but ended up discovering a whole chain of issues that led me down the rabbit hole of Google API approval processes.
The Cache That Never Cached
First problem: users connecting their Google Business Profile would see empty location lists forever. Turns out my handleGBPLocations function was only reading from a cache that was populated during the OAuth callback - but that initial fetch had been failing silently for weeks. Classic.
The fix was adding a live fetch fallback when the cache is empty, plus a 90-second throttle to prevent hammering Google's rate limits. Sometimes the simple solutions are the right ones.
The Null That Wasn't Null
Here's a fun one: when users wanted to disconnect a GBP location, my handleGBPClearLocation function wasn't actually clearing anything. I was using destructuring to omit the locationName key, but deepMerge preserves existing keys that aren't present in the source object.
Lesson learned: when you want to clear a field in the database, explicitly set it to null. Don't rely on omitting keys - that just preserves the old value.
The Quota That Never Was
But the real kicker came when I finally got the live fetching working and started seeing quota_limit_value: 0 errors. Turns out both GBP APIs I needed (mybusinessaccountmanagement.googleapis.com and mybusinessbusinessinformation.googleapis.com) require manual approval from Google.
Even if you enable the APIs in Google Cloud Console, your quota stays at zero until Google reviews and approves your use case through their business contact form. 1-3 business days, they say.
Building Better Error Messages
While waiting for Google's approval, I spent time fixing all the error handling. The frontend was showing generic "token may need refresh" messages for every failure type. Now it properly differentiates between:
- No GBP connection
- Expired token (401)
- Location not found (502)
- Quota/API access issues
Users deserve to know what's actually wrong instead of getting cryptic error messages.
The API Detective Agent
This session got complex enough that I created a new debugging agent - api-detective. It follows a 6-step investigation protocol for tracing API call chains:
- Identify the failing endpoint
- Check request/response logs
- Verify authentication
- Test API availability
- Check quotas and limits
- Escalate configuration issues
Having a systematic approach to API debugging saves so much time when things go sideways.
What's Next
Now I wait for Google to approve access to the GBP APIs. Once that comes through, the full audit flow should work automatically - all the infrastructure is in place.
Meanwhile, I can work on the Site Manager improvements: adding helpful tips for each option and building out the Site Migration flow for existing Cloudways users.
Six Cloudflare Worker deploys in one session might be a personal record, but hey - that's what happens when you're debugging API integration chains. Sometimes you just have to keep iterating until all the pieces fit together.
The uncommitted dashboard changes are sitting there waiting for the final test once Google gives us the green light. Should be any day now... š¤