Search for Planning Center website integration and you'll get WordPress plugins, a Zapier page, and a few widget vendors. If you're building a church site on something else, almost nothing is written for you. This is the shape of the work.
Pick the right credential first
Planning Center offers two paths and choosing wrong costs you a rewrite later.
A Personal Access Token belongs to a user inside one organization. It's the right choice when you're building for a single church, it takes a minute to create, and it's the fastest way to get a response back from the API.
An OAuth application is what you need if you're building something several churches will install. Planning Center suggests creating a separate organization to own the OAuth app. Start here if there's any chance this becomes a product, because migrating a live integration from PATs to OAuth is miserable.
Either way the token grants broad access to church data, so it belongs on a server. Never ship it to a browser, and never put it in a client bundle where View Source will find it.
The API is JSON:API
Planning Center's API follows the JSON:API specification, which matters more than it sounds. Relationships come back as references rather than nested objects, so the group list you fetch won't contain the related records you probably want, and you'll be using includes and a second pass to assemble what you need.
Budget real time for pagination and for the fact that a naive implementation makes far more requests than you expect. Rate limits are a thing you will meet.
Decide what you store
This is the architectural decision, and it's worth making deliberately. Fetching Planning Center on every page load ties your site's speed and uptime to someone else's API, and it means a crawler hitting fifty group pages triggers fifty API calls.
Storing a local copy and refreshing it on a schedule is almost always the better answer. Your pages render from your own database, they're fast, they work when the API is slow, and the content is in the HTML before any JavaScript runs. The cost is reconciliation: you have to notice when a group is unpublished or deleted, and withdraw your copy. Getting that wrong leaves ghost pages advertising groups that ended in March.
Where PCO Bridge fits
PCO Bridge runs a hosted server between Planning Center and your site. It handles the OAuth connection, keeps tokens encrypted server-side, and returns a normalized, privacy-safe view of published groups, so your site never holds Planning Center credentials and never talks to Planning Center directly.
A TypeScript SDK for exactly this case is in development rather than released, which is the honest status. If you're building a custom church site now and want to shape what that SDK looks like, the beta is where to say so.
PCO Bridge is in beta and applications are open to churches, developers, and agencies.