Feature Request: Add a /groups/v2/attendances?where[group]=123456 endpoint

[samuelkong]

Related Product
Groups

Is your feature request related to a problem? Please describe.
Retrieving attendance records for a group requires at least one API request for each of the group's event (via the /groups/v2/events/{event_id}/attendances endpoint), This is very inefficient for groups with a small membership and a long history of events.

Describe the solution you'd like
I'll like a endpoint such as /groups/v2/attendances?where[group]={group_id} or /groups/v2/groups/{group_id}/attendances so that I can retrieve all attendance records related to a specific group in large batches with fewer API requests to PCO.

Describe alternatives you've considered
CSV export of attendance report via the UI. However, this method isn't friendly to automation.

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

[github-actions]

Potentially Related Issues

I found some existing issues that may be related to this one. Please check if any of them address your question before waiting for a response:

🟣 #1429 — More efficient way to retrieve service schedule plan times (Closed)

Summary: This issue addressed the inefficiency of retrieving service schedule data by making individual API requests per person (thousands of requests). Similar to the new Groups issue, it sought a more efficient bulk endpoint to reduce API load when dealing with historical records across many entities.

Key discussion points:

• Original approach required one API request per person to get their service schedules, resulting in thousands of requests and hours-long sync times
• User wanted an endpoint to retrieve all schedules for all people at once, ordered by update date for incremental syncing
• Planning Center suggested an alternative approach: instead of N requests per person, make M+N requests (service types + plans), which yields far fewer requests since it only targets plans within the sync window
• Recommended using JSON:API sparse fieldsets to reduce response size by requesting only needed fields, improving performance further

Resolution: Rather than creating a new bulk endpoint, Planning Center provided an alternative API strategy that dramatically reduced requests: list service types, then get plans per service type filtered by date (rather than schedules per person). This approach makes M+N requests where N is only plans within the sync window (much smaller than total people count), avoiding empty responses. Combined with sparse fieldsets for requesting only needed fields, this solved the efficiency problem without requiring a new endpoint.

---

This comment was generated automatically. If none of these match your issue, no action is needed — a team member will review your issue soon.

[mariannamullens]

@samuelkong Thanks for the detailed feature request! I've added this use case to our tracker for improvements to the attendance API. I'm closing this issue for now, but we'll circle back with any updates.