Hi team,
First off — we run our whole social pipeline on your API and it's been rock solid.
One gap bit us hard last week, and the fix is probably cheap on your side, so here it is.
The situation: a restaurant client's Google account owns five GBP listings with the same name and address. One is verified and carries the reviews; the others are unverified shells.
Your connect-flow location list (GET /v1/connect/googlebusiness/locations) returns only id, name, address, category, storeCode — so the client picked blind, landed on an unverified shell, and Google's Performance API started answering 403 PERMISSION_DENIED while the account health stayed green. Debugging that took a while, because everything looked fine.
The request: enrich each row of the location list (connect flow and GET /v1/accounts/{id}/gmb-locations) with four fields you already serve elsewhere:
isVerified (from gmb-location-details -> location.isVerified)
hasBusinessAuthority (from gmb-verifications -> voiceOfMerchantState)
totalReviewCount / averageRating (from gmb-reviews)
placeId (from gmb-location-details)
With those, integrators can render "verified · 127 reviews · 4.8★" next to the right row, and users stop connecting empty shells.
Duplicate GBP listings are extremely common for restaurants, so this touches more accounts than you'd think.
Our current workaround (open-sourced here:
https://github.com/lipaonline/zernio-gmb-doctor)
cycles through the listings with PUT /v1/accounts/{id}/gmb-locations and probes the three per-selected-location endpoints for each — it works, but it's N×4 calls and briefly mutates the selection, which the picker could avoid entirely.
Happy to share more details or test a beta of the enriched payload.
Thanks! Patrick — platdujour.app
Please authenticate to join the conversation.
In Review
Feature Request
11 days ago

Patrick FAUST
Get notified by email when there are changes.
In Review
Feature Request
11 days ago

Patrick FAUST
Get notified by email when there are changes.