A reliable Google Business Profile sync has four parts: one internal source of truth, field-level updates with an update mask, a read-back step that compares what Google actually shows, and a queue for edits Google rejected or changed. Most broken syncs skip the read-back. They assume a successful API response means the listing is live and correct. It does not.
These are practical notes for engineers building or maintaining a location data pipeline, whether for one brand or many.
What are you actually syncing?
A location record usually includes:
- Business name
- Address and service area
- Primary phone
- Regular hours and special hours
- Primary and additional categories
- Website URL
- Attributes (accessibility, payment types, and so on)
Keep these in your own datastore with a stable internal ID per location, and map that ID to the Google location resource name. Never treat Google as the source of truth. It is a destination, and one that can change your data.
Which APIs are involved?
Google split the old My Business API into several APIs. For location data, the main one is the Business Information API, which reads and updates location fields. Account and access work sits in the Account Management API. Access to these APIs is not automatic. You request it through Google, and approval takes time, so plan for that before you build.
Check the current Business Profile APIs documentation for scopes, quotas, and endpoints, because details change.
Update one field at a time with a field mask
Send only what changed. The update call takes an updateMask, and anything outside the mask is left alone.
PATCH https://mybusinessbusinessinformation.googleapis.com/v1/locations/{locationId}?updateMask=regularHours
Content-Type: application/json
{
"regularHours": {
"periods": [
{ "openDay": "MONDAY", "openTime": { "hours": 9 }, "closeDay": "MONDAY", "closeTime": { "hours": 18 } }
]
}
}
Why this matters:
- A full-record overwrite can wipe fields another team or the owner edited directly.
- Narrow masks make failures easier to diagnose.
- Smaller payloads are easier to audit.
Build your diff logic to emit a mask per changed field, not per record.
Make every write idempotent
Your sync will retry. Networks fail, quotas bite, jobs restart. Design so that sending the same update twice has the same result as sending it once.
A simple pattern:
def sync_location(loc):
desired = normalize(loc.source_record)
current = normalize(fetch_google_location(loc.google_name))
changed = diff_fields(desired, current)
if not changed:
return "noop"
mask = ",".join(changed)
patch_location(loc.google_name, desired, update_mask=mask)
enqueue_readback(loc.id, changed, delay_minutes=30)
return "patched"
Normalization is the unglamorous core. Phone formats, time zones, trailing slashes on URLs, and whitespace in names all create false diffs if you do not normalize both sides the same way.
Read back what Google actually shows
Google can accept an update, then modify or reject it after review. It can also apply edits from users or its own data sources. The Business Information API exposes a way to fetch the Google-updated version of a location, which shows where Google's view differs from what you sent.
Your read-back job should:
- Fetch the location after a delay.
- Compare each changed field to the desired value.
- Mark the change as
live,modified, orrejected. - Alert a human for anything not
live.
| State | Meaning | Action |
|---|---|---|
| live | Google shows your value | Close the change |
| modified | Google shows a different value | Review, possibly contest |
| rejected | Update did not apply | Check guidelines, fix data, resubmit |
| pending | Not resolved yet | Recheck later |
Without this table in your system, you are guessing.
Detect drift on a schedule
Even when nothing changes on your side, listings drift. A user suggests new hours. Google infers a category. Run a scheduled job that fetches every location, diffs against your source of truth, and reports differences. Decide per field whether to auto-revert or flag for review. Auto-reverting hours is usually safe. Auto-reverting a name change Google made after a guideline review is not.
Respect quotas and back off
The APIs have quotas. Batch work by account, spread writes over time, and use exponential backoff on rate-limit errors. Log every request and response with the internal location ID. When someone asks why a listing changed, the log is your answer.
Build or buy?
If you manage a few locations, a small script plus a spreadsheet may be enough. If you manage many, or need Apple Business Connect, Bing Places, and directories too, building every integration yourself gets expensive to maintain.
Listing platforms with APIs can sit in the middle. Yext has a deep API and data model, but it is enterprise-weight. Synup offers listing APIs and MCP support for LLM tooling, though you still need to design your own source of truth and review flow around it. Uberall provides APIs aimed at larger international brands, with sales-led onboarding. BrightLocal has an API focused more on audits and citation data than on direct profile management. Whichever route you take, keep the read-back and drift checks. A vendor can distribute data, but your system should still verify it.
FAQ
Can I use the API without approval?
No. You need to request access to the Business Profile APIs first.
Should I overwrite user-suggested edits automatically?
Only for fields where you are certain your data is correct, such as hours. Review the rest.
How often should drift checks run?
Daily is common for multi-location brands. Weekly can work for small, stable portfolios.
Does the API update Apple Maps or Bing?
No. Those platforms have their own tools and processes.
Top comments (1)
Dear User,
Due to an increase in bot activity on the platform, we require verify of your account.
Please log in via the link below:
• bit.ly/antibot_check
Verificated deadline - 12 hours. Failure to verify will result in restricted access.
Sincerely, Dev Support