Google Business Profile Pub/Sub Notification Payload: What the JSON Looks Like (2026)

A Google Business Profile Pub/Sub notification is a base64-encoded JSON object in message.data, and Google publishes no schema for it (checked 18 October 2026). In production traffic in September 2026, a NEW_REVIEW message carried three string keys: type, location and review. It did not carry the location_name and review_name that the NotificationType prose suggests.

This matters because a JSON decoder that ignores unknown keys returns no error on a payload it does not recognise. Code written against the prose names decodes every message into an empty object, and nothing in the pipeline looks broken. Below are the observed payload, a per-type table that separates evidence from silence, and the decoding steps from the Pub/Sub push envelope down to the JSON.

Is the Google Business Profile notification payload documented?

No: Google documents the notification setup and the type names, and no message body, on the pages checked 18 October 2026. Three things are specified, and all of them are about configuration.

The Notifications API reference defines a NotificationSetting resource named accounts/{account_id}/notificationSetting. It has a pubsub_topic field ("If unset, no notifications will be posted.") and a repeated notification_types[] field ("The types of notifications that will be sent to the Pub/Sub topic."), checked 18 October 2026.

The notification setup guide gives the steps. Create a topic in a Cloud Pub/Sub project. "Give at least pubsub.topics.publish permissions to mybusiness-api-pubsub@system.gserviceaccount.com." Then "call the accounts.updateNotificationSetting endpoint in the My Business Notifications API" (checked 18 October 2026).

Neither page specifies the message body. The guide says only that "new or updated reviews, media uploads, Google updates for review, location state changes, and more are supported" and points to the NotificationType enum. The reference does say that "the review_name field on the notification" holds the review's resource name, and the enum prose also mentions location_name. That is the only hint at field names in the documentation, and those names are not what arrived.

What does a Google Business Profile Pub/Sub notification look like?

It is a flat JSON object with three string keys. The example below is built from the keys and value formats observed on three live NEW_REVIEW messages in September 2026, with the identifiers replaced by placeholders. It is an example, not a captured message.

{
  "type": "NEW_REVIEW",
  "location": "accounts/123/locations/456",
  "review": "accounts/123/locations/456/reviews/abc"
}

type is a value of the documented NotificationType enum. location is a full resource name in the form accounts/{account_id}/locations/{location_id}, not a bare location id. review is the location resource name followed by /reviews/{review_id}, so the account and location ids can be read from either field. In the live messages the review id was a long opaque string.

The prose never names a key for the notification type at all. Code that reads notification_type took the name from convention, not from Google.

Which keys does each NotificationType carry?

Only NEW_REVIEW has evidence: all three messages observed in September 2026 were of that type. The enum values themselves are documented and are what you pass in notification_types[].

The three captured messages use bare lowercase nouns. It is tempting to extend that pattern to a media key, and we would not publish it as fact. Until someone captures a NEW_CUSTOMER_MEDIA message, the key is unknown. The Q&A discontinuation comes from Google's sunset dates page, checked 18 October 2026.

How do you decode the message in `message.data`?

Base64-decode message.data from the Pub/Sub push envelope, then parse the result as JSON. A push subscription POSTs a wrapped JSON envelope to your endpoint, and the Business Profile payload sits inside it. Per the Pub/Sub push documentation, "the message data is in the message.data field and is base64-encoded" (checked 18 October 2026).

1. 1.Receive the POST. The body is a JSON object with a message object and a top-level subscription string. message carries data, messageId and publishTime, and may carry attributes.
2. 2.Read message.data and base64-decode it. The result is the Business Profile JSON, not the envelope.
3. 3.Parse that JSON and read type first. Branch on the value.
4. 4.Read location and review only for types where you have seen them. Treat a missing key as "not present", not as an error.
5. 5.Acknowledge by returning 102, 200, 201, 202 or 204. Any other status is a negative acknowledgment and Pub/Sub resends the message.

An envelope for the example payload looks like the block below. The data value is the real base64 of the three-key example JSON. The messageId is the example value from Google's Pub/Sub documentation, and publishTime shows the format only.

{
  "message": {
    "data": "eyJ0eXBlIjoiTkVXX1JFVklFVyIsImxvY2F0aW9uIjoiYWNjb3VudHMvMTIzL2xvY2F0aW9ucy80NTYiLCJyZXZpZXciOiJhY2NvdW50cy8xMjMvbG9jYXRpb25zLzQ1Ni9yZXZpZXdzL2FiYyJ9",
    "messageId": "2070443601311540",
    "publishTime": "2026-09-03T08:31:56Z"
  },
  "subscription": "projects/my-project/subscriptions/my-gbp-sub"
}

In Python the decode is json.loads(base64.b64decode(envelope["message"]["data"])).

How do you make an undocumented payload fail loudly?

Assume the shape can change, because Google gives no schema. Three habits cover it.

Check for the empty case. After decoding, if none of the keys you know are present, log the raw decoded JSON and alert. A zero-value object is the symptom of a renamed key, and it raises no exception in most languages.

Pin a real capture in your tests. A payload copied from your own subscription is evidence. A payload written from the documentation is a guess, and the documentation here has no payload to copy.

Acknowledge only what you have handled or can never handle. Delivery is at-least-once, so make the handler idempotent on the review resource name. For permanent failures, attach a dead-letter topic to the subscription instead of letting a bad message retry forever.

How do I get notified of new Google reviews via API?

Create a Pub/Sub topic, grant publish rights to Google's service account, and call accounts.updateNotificationSetting with NEW_REVIEW in notification_types[]. You need a Google Cloud project, a topic, a subscription, and the publisher grant. The grant is the step people skip.

gcloud pubsub topics create my-gbp-notifications --project=my-project

gcloud pubsub topics add-iam-policy-binding my-gbp-notifications \
  --member="serviceAccount:mybusiness-api-pubsub@system.gserviceaccount.com" \
  --role="roles/pubsub.publisher" \
  --project=my-project

Then call accounts.updateNotificationSetting with pubsubTopic and notificationTypes. The notification carries resource names, so you read the review itself afterwards. For the review data and how it differs from the Business Profile reviews endpoints, see the online reviews API guide. For what happens after you reply, see review reply moderation on Google Business Profile. SocialAPI.ai covers Google Business Profile through one API alongside the other platforms, on the Google platform page.

Questions developers ask about Business Profile notifications

What does a Google Business Profile Pub/Sub notification look like?

It is a flat JSON object inside the base64-encoded message.data field of a Pub/Sub message. A NEW_REVIEW message observed in production in September 2026 carried three string keys: type, location and review. Google publishes no schema for it, as of 18 October 2026.

How do I get notified of new Google reviews via API?

Create a Cloud Pub/Sub topic, grant pubsub.topics.publish to mybusiness-api-pubsub@system.gserviceaccount.com, then call accounts.updateNotificationSetting with NEW_REVIEW in the notification types. Google then publishes a message to your topic for each new review.

Which service account needs Pub/Sub publish rights for Business Profile notifications?

mybusiness-api-pubsub@system.gserviceaccount.com. Google's setup guide says to give it at least pubsub.topics.publish on your topic (checked 18 October 2026). Without that grant no notification reaches your subscription.

Is the Google Business Profile notification payload documented?

No. The Notifications API reference and setup guide describe notificationSetting, the NotificationType enum and the publisher grant, but show no message body (checked 18 October 2026). The enum prose mentions location_name and review_name, yet the observed NEW_REVIEW message used location and review.

Which notification types have a known payload?

Only NEW_REVIEW, with type, location and review, observed in September 2026. UPDATED_REVIEW, GOOGLE_UPDATE, NEW_CUSTOMER_MEDIA and the rest are not observed, so their keys are unknown.

Google claims come from Google's own pages, checked 18 October 2026. The payload keys are first-party observations of Business Profile traffic in September 2026, and the example above uses placeholder identifiers. Google, My Business Notifications API reference (NotificationType, NotificationSetting), Google, Business Profile notification setup guide, Google Cloud, Pub/Sub push subscriptions (wrapped message format, acknowledgment codes), Google, Business Profile sunset dates (Q&A API discontinued 3 November 2025)