PCO Bridge
All posts

What the Planning Center Groups API actually returns

Notes from building against it: the auth choice that's hard to undo, what JSON:API means in practice, and the reconciliation problem nobody warns you about.

Hands typing on a laptop beside an open notebook of hand-drawn boxes and arrows

Planning Center's API documentation covers endpoints and fields well. What it doesn't cover is the handful of decisions that shape your integration, and those are the ones that hurt to change later. These are notes from building against it rather than a replacement for the reference.

Choose auth before you write anything

A Personal Access Token belongs to a user in one organization and is the right call for a single church. An OAuth application is what you need for something multiple churches install, and Planning Center suggests creating a separate organization to own it.

Pick the second if there's any chance this becomes a product. Migrating a live integration from personal tokens to OAuth means reconnecting every church you've onboarded, which is the kind of email nobody wants to send.

JSON:API means assembly

The API follows the JSON:API specification. Relationships come back as references rather than nested objects, so the response you get is rarely the shape you want to render. Plan on includes and a second pass to assemble a group with everything attached to it.

Pagination and rate limits will find you faster than you expect, particularly if you fetch on page load rather than on a schedule.

Published is a property, not a filter you can forget

Planning Center decides whether a group is publicly visible, and your integration has to respect that on every refresh rather than only at import. A group that gets unpublished should disappear from your site.

The reconciliation problem

This is the part that separates a weekend project from something you can leave running. Creating and updating records from the API is easy. Noticing absence is not.

A group that was deleted or unpublished doesn't announce itself. Nothing arrives to tell you it's gone. You find out by walking the full collection and comparing it to what you're holding, and if you get that logic wrong you either leave ghost pages advertising groups that ended months ago, or you delete live groups because one paginated request failed.

PCO Bridge handles this by confirming missing groups individually after a complete traversal before withdrawing any local copy. Whatever you build, build something deliberate here rather than assuming a failed fetch means deletion.

Check the live docs

Field-level details change, so treat the official API reference as authoritative over any blog post, including this one. What's above is about shape and sequencing, which tends to stay true longer than field names do.

PCO Bridge is in beta and applications are open to churches, developers, and agencies.

Frequently Asked Questions

What format does the Planning Center API use?
It follows the JSON:API specification, so relationships come back as references rather than nested objects and you'll typically use includes plus a second pass to assemble a full record.
How do I know when a Planning Center group is deleted?
Nothing notifies you. You detect absence by walking the full collection and comparing it against what you hold, which is why a failed request should never be treated as a deletion.
Does the API tell me if a group is published?
Yes, publication is a property on the group, and your integration needs to respect it on every refresh rather than only at first import.