Check who can see a Chat space member list
The Google Chat API now exposes generally available controls over who can view a space's membership list. Google's September 23 developer release describes settings for target audiences and space roles, with both relevant fields required when making an update. This matters for districts that create or manage spaces through integrations: a successful creation request alone does not show that membership visibility matches the intended audience. The change concerns member-list visibility. It should be evaluated alongside the separate decisions about discovering a space, joining it and reading its content, rather than treated as a complete privacy configuration.
Why it matters for leaders
Editorial recommendation: The integration owner should test the actual result with accounts representing a manager, member and intended nonmember audience. Preserve the resulting settings with the integration's configuration record. Cost: allow for engineering and regression checks. Service: keep legitimate discovery usable. Risk: a group name or membership can itself be sensitive. Adoption: update provisioning templates only after role-based checks demonstrate the intended behavior.
Cost, service, risk & adoption
Dated developer release notes identify two membership-visibility fields and require both in the update mask and request body.
What the evidence cannot tell us
API general availability does not establish local licensing, application authorization or a tested district configuration. No local integration was changed for this report.
Read the original sources
Summary and leadership analysis from the Week ending 2026-09-25 brief. The edition’s selection notes explain source access and evidence limitations.