Google Business Profile reviews policy contract

Reviewed: 2026-08-26 UTC

Scope clarified: 2026-09-16. This contract governs the official Google Business Profile API acquisition method. The expanded Google Reviews design separately specifies Basic snapshots, DataForSEO and Outscraper, with explicit acquisition provenance, shared agency ownership and complete site credential overrides. Live Basic collection is proven; avatar validation and designer preview/save/binding remain in the first Basic capture gate. API-derived reviews or avatars must never be relabelled as Basic imports to bypass this contract. The quota guidance was rechecked on 2026-09-16; this scope amendment is not a fresh review of every policy source below.

Policy/access verdict: approval_required. A self-hosted installation may use the adapter only when its operator owns an approved Google Cloud project and is authorized to manage the selected Business Profiles. This report is not Google approval and makes no general reseller or service-provider access claim.

Local implementation status: F6.2a is complete. The reviewed adapter, owner-only installation credential setup, deterministic HTTP boundary, isolated temporary delivery, retention enforcement, explicit owner replies, and local-first disconnect lifecycle are installed in production composition. The catalog entry remains credentials_required until the separate F6.2b authorized live drill proves the installation-specific project, account, locations, branding treatment, and revocation behavior.

Primary sources

Business Profile APIs policies — access, third-party transparency, review authorization, disconnect, automated-use, temporary-storage, attribution, and branding rules; page last updated 2026-08-17 UTC when reviewed.
Prerequisites — verified profile, Cloud project, organization account, and API-access application requirements.
Basic setup — approved project, enabled APIs, OAuth client, business.manage scope, and the absence of a sandbox.
Implement OAuth — web OAuth, current and deprecated scopes, consent, refresh/access tokens, and offline access.
Account Management accounts.list — authorized-account discovery and pagination.
Business Information accounts.locations.list — location discovery, required read mask, and pagination.
Reviews list — review resource path, maximum page size 50, page token, ordering, aggregate response fields, and OAuth scope.
Work with review data — supported list/get/reply/delete-reply operations and review fields.
Reviews updateReply and Reviews deleteReply — explicit owner-reply mutation endpoints for verified locations.
Quota limits — 429 behavior, current API-specific quotas, even pacing, and exponential backoff with jitter.

Google can change these policies. Re-review the primary pages before a readiness promotion or policy-version change.

Access and credential model

DynoStatic supplies code, not a shared Google API project or credential-brokering service. Each self-hosted installation operator supplies an OAuth web-client ID and secret from a Google Cloud project it owns, for its own authorized Business Profiles.
That project must have Google approval for Business Profile API access and the required Account Management, Business Information, and Google My Business API surfaces enabled. A zero API quota means access has not been granted.
The installation requests only https://www.googleapis.com/auth/business.manage; the deprecated plus.business.manage scope is not requested.
The exact DynoStatic callback URI must be registered in the operator's OAuth client. The existing provider framework owns state, PKCE, administrator/website binding, encrypted tokens, expiry, refresh, and reconnect handling.
Google has no Business Profile API sandbox. Development evidence therefore uses deterministic HTTP fixtures. A real approval/account/location drill is separate F6.2b work and must never put credentials, tokens, review bodies, or unhashed remote identities in reports.
Google's policy text separately prohibits requiring end-clients to obtain supplemental projects while also requiring agencies/end-clients that make automatic or programmatic use to use their own projects rather than indirectly using a tool provider's project. The self-hosted design resolves this conservatively: DynoStatic never provides a shared project, and the installation operator applies for and operates its own project for its own use. Google approval of that concrete use remains authoritative.

Data and synchronization contract

Discovery lists only accounts accessible to the consenting user, then locations under a selected account. Every page token remains opaque and bounded. Location discovery requests only the minimum fields needed for a stable source identity, operator label, and attribution link.
Review synchronization uses the authorized accounts/{account}/locations/{location}/reviews surface with a maximum page size of 50 and stable updateTime desc ordering. It maps only review ID, reviewer display identity, star rating, comment, create/update timestamps, and existing owner reply needed for the review widget.
The adapter preserves provider/source identities, Google attribution, and available source links. It never presents Google content as first-party or implies Google endorsement.
A completed, fully paginated snapshot may reconcile reviews no longer returned by Google. An interrupted or partial snapshot may update observed rows but must not infer deletion of unseen rows.
Synchronization is scheduled no more aggressively than once every seven days by default. Manual synchronization remains bounded and uses the same job path. 429 responses and provider retry hints are honored; retries use bounded backoff and do not create parallel bursts.
Public rendering remains local and network-free. Failure to refresh never authorizes stale display: the implementation's 28-day ceiling makes Google content display-ineligible before 30 calendar days from its last successful observation. Public reads always exclude expired rows. Review administration and the bounded worker physically purge them; live Google use requires that worker to run at least daily because opportunistic traffic cannot guarantee deletion on a dormant installation.
Public Google review responses are provider-isolated, paginated in bounded 100-row windows, and sent with private, no-store without an ETag or stale application-cache entry. They do not enter a summary, minimum-rating filter, helpful-reaction path, or all-provider widget.

Storage and use restrictions

Google permits only limited, secure, temporary storage to improve project performance, for no more than 30 calendar days, and says stored content cannot be manipulated or aggregated. DynoStatic therefore applies all of these restrictions to content acquired through the official Business Profile API, including any future downloaded reviewer avatars:

no durable archive, indefinite cache, historical corpus, or disconnected retention;
no blending with first-party or other-provider reviews, blended rating, ranking, filtering, curation, rewriting, summarization, sentiment analysis, or AI generation/transformation;
no Import / Export payload, instance backup, local workspace pull, portable bundle, static content export, migration package, or third-party publication containing Google review content;
no use of Places or another Google surface as a substitute persistent review database;
no removal or alteration of Google attribution; and
immediate local purge on disconnect, with that website connection's access/refresh tokens destroyed before best-effort remote revocation. If revocation cannot be confirmed, DynoStatic persists a manual-remediation state and links the operator to the provider's connected-apps page; it never reports remote completion speculatively. The installation OAuth client remains in protected installation configuration until the installation owner explicitly forgets it. The UI provides the quick disassociation path required by Google and must never exceed Google's seven-business-day outer requirement.

The provider source identity, non-secret policy snapshot, audit fact that a connection existed, and sanitized operational error may remain when needed for integrity, provided they contain no Google review content or reusable credential.

The pending agency ownership design changes who owns a connection, not its API-content retention. Removing an inherited site's assignment must not revoke the shared account. Installation-wide disconnection is owner-controlled and identifies affected websites. Existing site-specific accounts must not become shared during migration. See the connection-recovery specification for the complete planned lifecycle.

Owner replies

Owner replies are optional manual actions, not synchronization side effects. Each create/update/delete requires an authorized administrator to open the exact Google review, enter or confirm the exact action, and submit it through CSRF-protected website-scoped administration. There is no bulk reply, scheduled reply, AI-written reply, rule-based reply, silent retry that duplicates a mutation, or API/workspace route for replies in this package. The operator remains responsible for Google's prohibited/restricted-content rules.

After a successful remote reply mutation, DynoStatic may update the temporary local projection or queue a bounded refresh. If the remote call throws after dispatch, its audit outcome is unknown, never falsely “not completed”: DynoStatic queues reconciliation and blocks another reply mutation until synchronization has reconciled the source. Audit records contain actor/action/remote identity facts but not reply bodies or credentials.

Readiness boundary

F6.2a is complete with deterministic fixtures, policy-isolation tests, real-MariaDB lifecycle/concurrency tests, responsive administrator coverage, and paginated public-runtime coverage, but google-reviews remains credentials_required. Promotion requires F6.2b to prove, with an operator-authorized project and account, OAuth connect, account/location discovery, multi-page review sync, forced token refresh, update/deletion reconciliation, explicit manual reply and delete-reply, rate-limit/retry behavior where safely observable, disconnect/revocation, purge, and reconnect. Until then there is no live-provider readiness claim.