Disconnect this company's Google Business Profile
/api/google-business/disconnectAdmin-only. Best-effort revokes the stored refresh token against Google's own /revoke endpoint BEFORE deleting the book_google_business_connections row (0090): a revoke that fails (already expired, a network blip) must not block the disconnect, or an owner trying to leave would be stuck because of the very connection they're trying to leave. Cached reviews in book_google_reviews are left as historical record, not deleted; they simply stop refreshing once the connection is gone.
Authorization
sessionCookie The dashboard's Supabase Auth session cookie, set at sign-in. Large sessions are split across
numbered chunks (…auth-token.0, .1), so treat this as a cookie family rather than one name.
Every request re-validates it against the Auth server (getUser()), never by decoding the cookie
locally: a JWT nothing has checked is not a credential. Tenancy is then read from the verified
app_metadata.company_id claim and enforced by row-level security; it is never read from request
input, on any route, ever.
role (admin / staff) is deliberately not in RLS. It gates specific actions in route code,
the operations marked admin below, so hiding a button in the UI is cosmetic only, and a route's
own check is the enforcement.
In: cookie
Response Body
application/json
application/json
application/json
curl -X POST "https://example.com/api/google-business/disconnect"{ "ok": true}Google OAuth callback: exchange the code, resolve the location, store the connection GET
Where Google sends the browser back to after the owner grants or denies consent: same browser, same session as `/connect`, which is why this reuses `requireMember('admin')` rather than a separate scheme. Validates `state` against the `gbp_oauth_state` cookie `/connect` set; a mismatch (or missing cookie) is `gbp_error=state_mismatch` rather than proceeding. Exchanges `code` for tokens, requires a refresh token to be present (a fresh grant with `prompt=consent` should always include one; a response without one is refused rather than silently stored access-token-only, which would look connected and stop working the moment that token expires). **v1 assumes one Google Business Profile location per connection**, matching this app's own one-`book_companies`-row-per-physical-location model. Takes the caller's first Google account, then within it the location whose `metadata.placeId` matches this company's own `google_place_id` (0031, the same id already captured for free during onboarding's Places search), falling back to that account's first location when there is no match or the company never ran that search. A business with several GBP locations connecting the wrong one is a documented v1 limitation (docs/google-business-profile.md), not a silent bug. Stores the connection via `book_google_business_connections` (0090): a refresh token AES-256-GCM encrypted at rest, an access token cached alongside it. The Google account's email is read from the signed-in admin's own session, not from Google's token response (which doesn't include it), since a fifth external call for a label shown for reassurance only was not worth it.
Reply to a Google review from this app's own dashboard POST
Admin-only. `reviewId` is this app's own `book_google_reviews.id` (0090), not Google's resource name: the client never needs to learn Google's naming scheme. Scoped by `company_id` explicitly in the lookup, not by id alone: that table has no SELECT policy for `authenticated` at all, so this IS the tenant boundary, same shape `reviews/page.tsx`'s own `book_feedback` read already relies on. Calls Google's `reviews.updateReply` (v4; reviews were never migrated off that surface when the rest of the My Business API was decomposed into v1 services; see docs/google-business-profile.md), which creates a reply if none exists or replaces one that does; there is no separate edit endpoint. On success, best-effort mirrors the reply into the cached row so the dashboard shows "already replied" without a live call. A failure there is only stale UI, since the reply already succeeded on Google's side, and the next sync overwrites it either way.