What the attributes workflow manages
Attributes are structured facts Google can show on a business profile: payment methods, accessibility options, service options, ownership-related labels, parking, pickup, delivery, amenities, and other category-dependent details. They are not free-form profile copy. They need exact attribute IDs and value shapes.
Endpoint and payload shape
Use GET /api/v1/misc/google-business/location/attributes to read current attributes, GET /api/v1/misc/google-business/location/attributes/available to list supported definitions, and PATCH /api/v1/misc/google-business/location/attributes to update attributes. PATCH accepts attributes and can derive attributeMask from attributes[].name when needed.
Value types you need to handle
Attribute values are not all the same shape. Boolean attributes use values arrays such as values: [true]. Multi-enum attributes use repeatedEnumValue with setValues. URL-style attributes can use uriValues. Your UI should inspect available definitions instead of assuming every attribute is a simple checkbox.
Where teams usually get stuck
Attribute availability depends on category, region, language context, and Google’s current catalog. A valid attribute for one location can be invalid for another. The right flow is list available definitions, get current attributes, then patch only supported names and values.
How bundle.social fits
bundle.social exposes attribute discovery and updates beside the rest of the Google Business Profile workflow. That lets your product build real editable profile fields without guessing which Google attributes are allowed for a selected business location.