BUG: All calls to /registrations/v2/signups/:id/registrations return 403

[aberamseyer]

Affected Product
Which product does this bug affect?
Registrations

Describe the bug
Despite having access to the Registrations application, all calls to return the registrations for a signup return a 403. This has broken integrations for over 100 customers. This began happening around 12 hours ago.

To Reproduce
In the api explorer, navigate to Signups -> choose an id, then "registrations" for that signup: http://api.planningcenteronline.com/registrations/v2/signups/:id/registrations

Expected behavior
Authorization to access /registrations/v2/signups should imply access to all child resources

Screenshots

Additional Context:

• Authentication: PAT

I have..

• Reviewed the documentation found at https://developer.planning.center/docs
• Searched for previous issues reporting this bug
• 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:

🟣 #1331 — Registrations Signups Attendees: 404 error (Closed)

Summary: User reported 404 errors when accessing /registrations/v2/attendees and /signups/{signup_id}/attendees endpoints, which appeared to work in API Explorer but failed with their PAT. Similar to the new issue's 403 errors, this involved permission/access problems with signup child resources.

Key discussion points:

• Initial diagnosis focused on whether user had appropriate access (org admin or signup manager)
• User confirmed they were an org admin, indicating it wasn't a straightforward permissions issue
• Issue was moved to private email communication for resolution

Resolution: The issue was resolved through private email correspondence with Planning Center support. The specific fix is not documented in the public thread, but it was confirmed resolved when the issue was closed on 2025-07-08.

🟣 #1336 — Personal Access Token API Version Lock Bug (Closed)

Summary: User experienced 404 errors when calling /signups/{signup_id}/attendees which worked in API Explorer but failed in their code. Root cause was PAT API version settings not being applied correctly, requiring explicit X-PCO-API-Version header. Demonstrates version-related access issues with signup child resources.

Key discussion points:

• Setting PAT API version to 2025-05-01 in the GUI didn't take effect - requests were still using old version
• Adding explicit X-PCO-API-Version: 2025-05-01 header resolved the 404 errors
• The attendees endpoint doesn't exist in the 2018-08-01 API version
• Browser requests default to oldest API version and don't use PAT credentials

Resolution: Workaround: explicitly set X-PCO-API-Version header to 2025-05-01. The underlying PAT version setting bug was not confirmed as reproduced by the Planning Center team when they tested with curl commands.

🟣 #1333 — Registrations Attendees 500 Errror (Closed)

Summary: User reported 500 errors when accessing /signups/{signup_id}/attendees/{attendee_id}, which was quickly fixed. However, deeper nested resources like emergency_contact then returned 403 errors despite org admin rights. Shows permission handling issues with deeply nested signup resources.

Key discussion points:

• Initial 500 error was quickly fixed by Planning Center
• After fix, accessing nested resources (emergency_contact) returned 403 errors even for org admins
• Workaround provided: use include=emergency_contact parameter on attendee request instead of separate nested call
• Permissions were not being handled correctly for deeply nested resource paths

Resolution: Planning Center deployed a fix on 2025-07-08 that corrected permission handling for deeply nested resources under signups. The issue was confirmed resolved by the reporter.

🟣 #1374 — Apis under registration/v2/signups/{id}/selectiontypes works in API Explorer but not when url is called in a browser (Closed)

Summary: User reported that /signups/{id}/selection_types returned 404 errors when called directly but worked in API Explorer. Also noted that links in /signups responses still referenced deprecated /events endpoints instead of /signups. Eventually determined to be a version mismatch issue.

Key discussion points:

• Links returned in signup responses still pointed to old /events/{id}/attendee_types format instead of /signups/{id}/selection_types
• selection_types endpoint returned 404 when called directly but worked in API Explorer
• Discrepancy was due to user's code hitting legacy API version while docs/explorer used 2025-05-01
• User had not updated API version setting in their PAT console configuration

Resolution: User resolved the issue themselves by updating the API version setting in their PAT console to 2025-05-01. This was a configuration issue rather than a bug - the user needed to explicitly opt into the new API version.

---

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

[michaelhvisser]

Seeing this on a second organization as well — confirming it's not isolated.

Same error, on every RegistrationVertex read:

{"errors":[{"status":"403","title":"Forbidden","detail":"You do not have access to this resource",
"meta":{"description":"User with id cannot read AppGraph::V2025_05_01::Vertices::RegistrationVertex collection."}}]}

A few additional data points that may help narrow it down:

• Reproducible via both OAuth 2.0 and PAT (this issue currently notes PAT only). Both auth methods resolve to the same user and return the identical 403, so it's not auth-method-specific.
• The acting user is a confirmed Organization Administrator — shows as "Org Admin / can create, view, and modify all signups" in the Registrations app UI. So org-admin status is not being honored for this vertex.
• Denial is vertex-wide, not per-signup. All of these 403 identically:
  • GET /registrations/v2/signups/:id/registrations (multiple different signup ids)
  • GET /registrations/v2/registrations (top-level collection)
  • with and without ?include=created_by,registrant_contact
• Every sibling resource reads fine (200) with the same credentials: signups, signups/:id, signups/:id/attendees, etc. Only RegistrationVertex is blocked.
• On a readable signup, meta.can_include omits registrations even though it's listed under links — consistent with the vertex being walled off everywhere.

Timing matches the original report (started ~June 10–11). Happy to provide org id / request ids privately if that helps triage.

[dannytan]

Confirming we are seeing this across multiple orgs as well. Responses flipped to 403 between 2026-06-10 and 2026-06-11 for GET /registrations/v2/registrations with nothing changing on our end.

[robertleib]

A fix went out about 2 hours ago that should have fixed this. @dannytan can you confirm you are still seeing this right now?

[dannytan]

@robertleib Yes still seeing it in the API Explorer:

Let me know if you need any other info that might help!

[aberamseyer]

registrations/v2/signups/:id/registrations is fixed, but as dannytan said, registrations/v2/registrations is still broken

[JoshHarris85]

Hello everyone, a fix should be live now for the registrations/v2/registrations endpoint. If you have the same result using the API explorer, it's probably worth clearing your browser data for that site.

If you do still have trouble in any way just let us know. We'll try to get it worked out for you ASAP.

[dannytan]

Confirmed it's working now on my end. Thanks, @JoshHarris85