HubSpot + Planning Center integration

Churches and the nonprofits around them run on relationships nobody can see in one place. Planning Center holds the membership roll, the small groups, the check-in history and the giving record, split across products that each do one job well. What none of them do is campaign. A ministry lead who wants to reach every family that attended twice and then stopped is opening three apps and exporting from all of them.

Giving makes the gap concrete. A church knows which households give, how often and to which fund. Turning that into a stewardship programme, with lapsed donor sequences and a thank-you that arrives without anyone typing it, needs the giving record somewhere a workflow can read.

Assimilation is the other half. A first-time visitor checks in, joins a group six weeks later, and serves a year after that. Each step is recorded in a different product, and the follow-up in between gets done by volunteers from memory. Putting the person, their household, their groups and their check-ins into one portal turns that path into a sequence rather than a hope.

The line we hold is the one a nonprofit board would draw anyway. Planning Center stays the system of record for the person and the gift. HubSpot becomes the place outreach gets planned and measured.

Six record types do the work. The person becomes a contact keyed on the Planning Center person identifier. The household becomes a company, and group membership becomes an association rather than a property, because one person belongs to several groups and a property field cannot carry that.

Donations become a custom object on the contact, holding the amount, the date and the fund. Check-ins come across as engagements, which keeps attendance on the timeline where a person’s history belongs without inflating the contact record with hundreds of fields.

What stays out is anything a church would not put in a marketing tool by default. Notes, care records and anything a pastor entered are reachable through the same API and are simply not part of the mapping. A donor’s payment details never move at all. As with any sensitive category, bringing more across is a decision made with HubSpot’s sensitive data settings switched on and a written policy behind it, not a mapping choice made quietly during a build.

Planning Center publishes proper webhooks, and the documentation is direct about how they behave. A subscription is managed under a user account, each delivery carries an HMAC-SHA256 digest in an authenticity header keyed on the subscription secret, and a failed delivery is retried up to sixteen times on a backoff running from 30 seconds out to four days. Deliveries carry no rate limit of their own.

The runtime is therefore a receiver, a queue and a worker. The worker verifies the digest, reads the full record back through the API, and writes HubSpot as an idempotent batch upsert keyed on the Planning Center identifier, with a separate associations pass for households, groups and donations.

Reads are filtered rather than exhaustive. The API follows the JSON-API specification and supports greater-than and less-than comparisons on dates through its where parameters, so a reconciliation sweep asks for what changed after a stored watermark instead of paging the entire roll each night.

Automation platforms are the listed route, and they are a fair one for a narrow job. A church that wants new people in Planning Center to appear as HubSpot contacts, and nothing more, can wire that in an afternoon without an engineer anywhere near it.

Volume is what breaks that. Check-ins and donations are the high-cardinality records, and a per-task platform charges for every single one. A congregation of a few hundred families produces thousands of check-ins a month, which is precisely the pattern per-task pricing punishes. Shape breaks it too. Households, group membership and fund-level giving are associations and custom objects, and mapping tools handle those badly or not at all.

A keyed service is the answer once giving or attendance is in scope. It also lets the church state its own field and retention policy, which matters more in a donor context than in most.

A church sync trips on the same few things, starting with a rate limit that is tighter than it looks.

1. Scope. We agree which products are in scope, People alone or People with Giving, Groups and Check-Ins, and write down what may be synced from each one.
2. Architect. The object model, the identifier property per record type, the household and group association design, and the fund mapping for giving.
3. Build. The webhook receiver with authenticity verification, the queue, the worker, and the filtered sweep that reconciles whatever the events missed.
4. Validate. A sandbox portal first, behind a fail-closed portal allowlist so a misconfigured token cannot write into the wrong portal. Production cutover is a token swap.
5. Operate. Subscription health checks, a replay from a chosen watermark, a reconciliation count of active people on both sides, and pacing a church office never has to think about.