What the location workflow manages
This workflow reads and updates the core Google Business Profile location resource. It covers profile-facing data such as display name, description, website URL, phone numbers, categories, storefront address, service area, coordinates, open status, hours-related fields, and Google metadata.
Endpoint and payload shape
Use GET /api/v1/misc/google-business/location to read a selected location and PATCH /api/v1/misc/google-business/location to update it. GET accepts fields as comma-separated or repeated query params. PATCH sends only the top-level keys included in your update payload.
Patchable fields
Patchable fields include title, profile, websiteUri, phoneNumbers, categories, storefrontAddress, regularHours, specialHours, moreHours, openInfo, serviceArea, and latlng. Use validateOnly when you want Google to validate the payload before applying it.
Where teams usually get stuck
Google Business Profile fields are location-specific and often category-dependent. A field that works for one branch may be read-only, unsupported, invalid, or risky for another branch. Your UI should read current state before patching and surface Google validation messages clearly.
Eligibility metadata you should not ignore
The location metadata can tell you whether feature families are available. For example, canModifyServiceList controls whether service list editing should be enabled, and canHaveFoodMenus controls whether food menus should be shown in the product. Use metadata to avoid fake buttons that lead to rejected API calls.
How bundle.social fits
bundle.social keeps location profile management next to posts, reviews, media, account operations, and analytics. That makes it easier to build one operational dashboard for local profiles instead of duct-taping a separate Google Business Profile integration onto your app.