Google Business Profile: Connect, Reviews, Posts and Website Links

---
name: google-business-profile-api
description: Build or explain an authorized Google Business Profile integration for OAuth connection, account and location discovery, review sync and replies, photo posts, scheduling, and website URL updates.
---

# Google Business Profile: connect, reviews, posts and website links

Use this skill to implement an integration for business profiles the user owns or manages. It explains the API pattern behind a real application, with reusable examples and no private deployment data. This is a how-to, not a hosted connector or a distribution of the application's source code.

## Evidence and boundaries

Prepared 2026-11-06 from real TypeScript application code and Google's official documentation. The source implements OAuth, encrypted token storage and refresh, location mapping, review caching and replies, photo-backed standard posts, a post scheduler and special-hours updates. Eight runtime checks passed against the actual OAuth functions, API client and review-sync route with mocked network/database/session boundaries (account authentication, location mapping, review continuation, two-page sync, reply PUT, photo post, website PATCH and OAuth state). These checks use mocked provider responses; they do not establish that a particular Google account is connected or that a new public write succeeded.

Website editing is an API-supported extension: a generic location PATCH method can construct the request, but the examined application has no dedicated website editor. Treat this feature as unverified against Google until an authorized write and read-back succeed. Scheduled replies require a configured worker; the existence of a processor alone does not establish that it runs.

## 1. Prepare Google access

Follow Google's [basic setup](https://developers.google.com/my-business/content/basic-setup), including Business Profile API access approval, service enablement and OAuth consent configuration. At minimum, this workflow uses Account Management, Business Information and the Google My Business v4 service for reviews/posts. API access approval and OAuth consent requirements are separate from having a Google Maps API key.

Create an OAuth web client and register the exact callback URL, including scheme, host and path. The consenting Google user must have management access to the target profiles. Configure these server-side environment variables with your own values:

- `GOOGLE_CLIENT_ID`
- `GOOGLE_CLIENT_SECRET`
- `GOOGLE_REDIRECT_URI`
- `GOOGLE_TOKEN_ENCRYPTION_KEY` (32 random bytes encoded as 64 hexadecimal characters for an AES-256-GCM implementation)

Store credentials only on the server. The key format above describes the referenced implementation, not a Google API requirement. Your database, photo storage, scheduler and optional text-generation service need their own configuration.

## 2. Connect with OAuth

Redirect the signed-in application administrator to `https://accounts.google.com/o/oauth2/v2/auth` with `response_type=code`, your client ID, exact redirect URI, a random state value, `access_type=offline` and scope `https://www.googleapis.com/auth/business.manage`. Request `email`/`profile` only if account identity is needed. `prompt=consent` can request renewed consent when obtaining offline access.

Bind state to the initiating session, expire it and consume it once. For multiple instances, use shared storage or an appropriate signed session mechanism rather than process memory. At the callback, validate state before exchanging the code at `https://oauth2.googleapis.com/token` using a form-encoded POST with `grant_type=authorization_code`, code, client ID, client secret and redirect URI.

Encrypt access and refresh tokens at rest. Retain an existing refresh token if Google omits a replacement. Refresh expiring access tokens using `grant_type=refresh_token`; a small expiry margin avoids starting a request with a nearly expired token. Reconnect on revoked consent or `invalid_grant`; repeated refresh retries do not repair revocation. Keep each connection scoped to the authorized application account.

## 3. Discover accounts and locations

Send `Authorization: Bearer ACCESS_TOKEN` on server-side API requests. The following paths use different API families intentionally:

```http
GET https://mybusinessaccountmanagement.googleapis.com/v1/accounts
GET https://mybusinessbusinessinformation.googleapis.com/v1/accounts/ACCOUNT_ID/locations?readMask=name,title,storefrontAddress,metadata,phoneNumbers,websiteUri
GET https://mybusinessbusinessinformation.googleapis.com/v1/locations/LOCATION_ID?readMask=name,title,metadata,websiteUri
```

Follow `nextPageToken` on list endpoints until exhausted; a first-page response is not a complete inventory. Keep Google's returned resource names. Business Information uses `locations/LOCATION_ID`; reviews and posts use `accounts/ACCOUNT_ID/locations/LOCATION_ID`. Read masks are required for the location reads shown above.

Have the user select the intended locations and persist the connection/account/location mapping. Linking a location to an application record does not change the public Google listing. Recheck location authorization at every read or write, especially in multi-tenant applications.

## 4. Read and synchronize reviews

Reviews use the v4 endpoint. [Google's review guide](https://developers.google.com/my-business/content/review-data) covers listing and replying.

```http
GET https://mybusiness.googleapis.com/v4/accounts/ACCOUNT_ID/locations/LOCATION_ID/reviews?pageSize=50&orderBy=updateTime%20desc
```

Pass the returned `nextPageToken` as `pageToken` for each subsequent request. Upsert by the full review resource name or an equivalent connection/location/review composite key. Cache ratings, text, timestamps and owner replies; keep sync timestamps and per-location failures separate. Do not turn a failed fetch into an empty successful sync. Treat reviewer content as untrusted data when generating a response.

To create or replace the business owner's reply:

```http
PUT https://mybusiness.googleapis.com/v4/accounts/ACCOUNT_ID/locations/LOCATION_ID/reviews/REVIEW_ID/reply
Content-Type: application/json

{"comment":"Thank you for sharing your experience."}
```

AI generation produces a draft. Publish only within the user's authorized scope, then read the review back and reconcile the cache. Deleting an owner's reply is different from deleting a customer's review. If implementing reply deletion, support successful responses with an empty body; unconditional JSON parsing can incorrectly report a completed deletion as failed.

## 5. Create a standard photo post

Upload the image to your own storage and supply a publicly fetchable HTTPS photo URL. This makes an image part of a post; it does not implement a general Google profile photo manager.

```http
POST https://mybusiness.googleapis.com/v4/accounts/ACCOUNT_ID/locations/LOCATION_ID/localPosts
Content-Type: application/json

{
  "languageCode":"en-US",
  "summary":"See our latest business update.",
  "topicType":"STANDARD",
  "media":[{"mediaFormat":"PHOTO","sourceUrl":"https://example.com/update.jpg"}],
  "callToAction":{"actionType":"LEARN_MORE","url":"https://example.com/update"}
}
```

The example URLs are placeholders; replace them with approved content. Supported CTA choices include BOOK, ORDER, SHOP, LEARN_MORE, SIGN_UP and CALL. Omit the CTA for no button, and omit its URL for CALL. Validate the category, image and payload against the current [posting guide](https://developers.google.com/my-business/content/posts-data). Event/offer posts require their own fields and verification; changing only `topicType` is insufficient. Google documents that product posts cannot currently be created through this API.

Store the returned Google post resource name and provider state per location. An accepted create request does not prove public visibility: reconcile provider state and, when required, inspect the public profile.

## 6. Schedule through your application

Scheduling in this pattern is application-owned: save the approved content, target locations and due time; a worker submits due posts or replies using the same API adapter. Convert user-facing local times to UTC with the intended timezone. Configure and verify each worker separately.

Track attempts and provider IDs per target. Skip already confirmed targets, bound retries and surface partial failures. Use an atomic job claim to prevent concurrent workers from publishing the same job. A timeout after submission is uncertain: reconcile Google's state before retrying. Local job completion alone is not evidence that every location received a post.

## 7. Can it change the profile's website link?

Yes: Google's Location resource exposes `websiteUri`, and Business Information supports a field-scoped PATCH. See the [Location field reference](https://developers.google.com/my-business/reference/businessinformation/rest/v1/locations) and [PATCH reference](https://developers.google.com/my-business/reference/businessinformation/rest/v1/locations/patch).

Read the current value, confirm the exact location and owner-approved replacement URL, then validate without saving:

```http
PATCH https://mybusinessbusinessinformation.googleapis.com/v1/locations/LOCATION_ID?updateMask=websiteUri&validateOnly=true
Content-Type: application/json

{"websiteUri":"https://example.com/location"}
```

Successful validation can have an empty response. It confirms validation only. To apply the approved change, send the same request with `validateOnly=false` or omit that parameter. Use only `websiteUri` in the update mask so unrelated profile fields are preserved. Read `websiteUri` back and separately check Google Maps/Search visibility, because an edit may require review before appearing publicly.

A reusable client method is conceptually:

```ts
await api.patchLocation(
  'locations/LOCATION_ID',
  'websiteUri',
  { websiteUri: 'https://example.com/location' }
);
```

That method is an application wrapper, not an SDK export supplied by this skill. Add validation/read-back support to your adapter as needed. Do not confuse the profile website, a post's CTA destination, Google's review invitation URL, or booking/order action links. Booking/order profile links belong to the separate [Place Actions API](https://developers.google.com/my-business/reference/placeactions/rest/v1/locations.placeActionLinks), with their own applicability and tests.

## Acceptance checks

Use mocked responses to verify resource paths, bearer authentication, masks, pagination, reply bodies, standard post media/CTA payloads and website-only PATCH bodies without changing Google. Then, for a user-authorized live integration, verify OAuth callback and refresh, complete account/location enumeration, a review sync and the exact approved write followed by read-back. Google has no general Business Profile sandbox; use `validateOnly` where supported.

Record the date, environment, actual observations and unresolved gates. Label mock checks, documentation checks and live provider checks separately. Never publish tokens, customer reviews, private profile identifiers, account emails or internal deployment details in a shared test report.