Access Schedules Are Community-Keys-Only
What changed: Key access schedules now apply to a community’s own keys only. The list endpoint no longer returns member keys, and reading or writing a member key’s schedule is refused with 403 not_a_community_key. A community manager was never meant to change one member’s schedule — the community-wide rule is what they set, and it already cascades to every member beneath the community key.
Where to find it: GET /v1/community/key-schedules, GET|PUT /v1/community/keys/{key_id}/schedule
What you’ll see: A shorter list containing only the community’s own key(s). descendant_key_count now counts live member keys only — one community reported 1,115 where the true figure was 804. The list also returns only the windows in force today, reporting anything expired as the new inactive_window_count so an expired schedule is never mistaken for no schedule. Single-key reads still return every window, since a write replaces the whole schedule.
What you need to do: If your integration scheduled member keys, switch to scheduling the community key — the restriction reaches the same members. This is a breaking change, taken because these endpoints had never been called in production, so no live integration is affected.
Who this affects: Customers building on the public API