Groups: expose group membership change history (joins and leaves over time)

[michaelhvisser]

Related Product

Groups

Is your feature request related to a problem? Please describe.

The Groups API can tell me who is in a group right now, but not how that group
changed over time. When someone leaves a group, the Membership record is
destroyed and the fact that they were ever there goes with it.

Checked against https://api.planningcenteronline.com/groups/v2/open_api/2023-07-10:

• The Membership schema carries exactly two attributes: joined_at and role.
  There is no left_at, ended_at, removed_at or equivalent.
• None of the 90 documented paths is a membership history, stats or turnover
  endpoint.
• The strings left_at, ended_at, removed and turnover do not appear
  anywhere in the spec.

I can confirm the record is genuinely gone rather than hidden: summing
memberships_count across groups matches the number of Membership rows I can
retrieve, so a departed member is not simply filtered out of my results.

What makes this one frustrating is that Planning Center already computes this
data and shows it to churches. The Groups Reports page
(groups.planningcenteronline.com/reports) renders a 90-day turnover health
stat and a Group Membership over time chart that rises and falls across the
year. Those figures are server-rendered into the page — there is no API behind
them I can reach.

Why it matters: someone leaving a group is one of the clearest pastoral signals a
church has, and there is a real difference between going quiet and telling us
they are leaving. Today the API can only support the first. A church can see
that attendance stopped; it cannot see that the person formally left, or when.

Describe the solution you'd like

A read-only endpoint exposing per-person group membership changes:

GET /groups/v2/groups/{group_id}/membership_changes

and/or an org-wide GET /groups/v2/membership_changes

Each record carrying:

• person_id
• group_id
• action — joined or left
• occurred_at
• role at the time of the change (member / leader), so leadership transitions
  are visible too

With the usual JSON:API conventions: pagination, order, where[] filtering on
group and date range, and include=person. Readable under the existing Groups
scope.

Historical backfill would make this far more valuable than
subscribe-from-today. A church connecting an integration should be able to chart
the last year, not begin accumulating from scratch — particularly since the
Reports UI proves the history is already there.

Secondary ask, if per-person change records cannot be exposed: either

1. a left_at / ended_at attribute retained on Membership for ended
   memberships, or
2. a per-group membership count history — date plus member count per period —
   which is what the Group Membership over time chart is already built from.

Option 2 would at least make trend reporting possible, though it cannot support
a join/leave feed or any follow-up trigger.

Describe alternatives you've considered

1. Polling /groups/v2/memberships and diffing client-side. This is what I
   do today. It works, but every integrator independently rebuilds the same
   snapshot store, it only produces history from the day the church connects,
   and it misses anything that happens between polls.

2. Comparing memberships_count to detect churn. Cheaper than a full walk,
   but structurally blind to count-preserving churn: one person joins as another
   leaves, the count is identical, and nothing appears to have changed. In an
   active group that is a common shape, not an edge case.

3. Webhook-driven diffing. Closer to real time, but it cannot backfill —
   a church gets history only from the day the subscription starts, and anything
   that happened before the integration existed is unrecoverable.

4. Deriving departure from absence. Inferring that someone left because they
   stopped appearing in attendance. This conflates the two cases the church most
   needs to tell apart, and it produces false positives for anyone who is simply
   travelling or unwell.

Additional context

This is the Groups counterpart to #1497, which asked the same thing for People
lists and was closed on 2026-09-15 as taken under consideration. #1234 received
the clarifying answer that the API only exposes non-deleted resources, which is
consistent with what I see here — this request is specifically that ended
memberships, or a record of their ending, become retrievable.

Happy to give more detail on the use case if it helps.

I have..

• Reviewed the documentation found at https://developer.planning.center/docs
• Searched for previous issues asking for this feature request
• Removed all private information from this issue (credentials, tokens, emails, phone numbers, etc.)
• Reviewed my issue for completeness

[americanmouths]

Hi @michaelhvisser! Thanks for the detailed write-up and letting us know about your use case.

It's correct that the API only exposes active memberships today. In most cases, membership records are soft-deleted and we retain a deleted_at timestamp, which is what is used to power the Reports page. However, there are scenarios where the records are permanently removed so relying on the deleted_at wouldn't be sufficient for every case.

I am going to go ahead and close this issue but I will capture this as a feature request and use this as helpful context as we evaluate what we might be able to expose here.