CourtReserve to HubSpot for a 16-location pickleball franchise, then handed over

The franchise was growing quickly, and every club ran its own bookings, events and memberships in the same court management platform. Head office could not answer two basic questions: what a member is worth, and when they last played. The answer sat in one account per club, with no view across them.

The platform’s API set the shape of anything we could build. Each club is a separate organization with its own credential, so there is no single tenant wide key to hold. A request may cover at most 31 days, so a historical backfill is a loop over windows rather than one call. There are no webhooks, no bulk endpoints and no test environment, so a nightly poll against production is the only honest design. On the HubSpot side, email is globally unique, so a person who plays at three clubs cannot be three contacts, and yet the franchise needed to see all three clubs on that one record. The operator also wanted to own the system at the end of it, which ruled out anything only we could run.

The sync runs once a night, one club at a time. For each club it pulls the last 2 days of members, reservations, events, event registrations, memberships and transactions, fetches the HubSpot records it already knows about, then writes.

Members become contacts, upserted on email inside the club’s own scope, falling back to the platform’s member id where a member has no email address. Three properties carry the multi-location problem. A multi-select holds every club a member has played at and is merged rather than replaced, a single select holds the primary club and is set only on creation, and a third records which club synced the contact last. When a batch create hits the global email uniqueness rule, the handler re-queries the existing contact, merges the club set into it and patches. The second club to sync a shared member adds to the record instead of failing against it.

Reservations, events, event registrations and memberships each become a custom object with its own dedupe key written as a property, and transactions become deals. Associations run as a separate pass after the writes, so no record waits on the thing it points at. Rate limiting is deliberate: one club at a time, a floor on the interval between requests, and a retry that honours the platform’s own backoff header. A portal allowlist fails the run closed when the connected portal is not the one the environment expects. After the writes land, a second phase recomputes first visit, last visit, visits in the last 30 days and monthly spend on every contact, so the rollups always describe data that was just synced.

The sync went live in April 2026 across 15 club locations. The first full rollup pass patched 91,697 contacts with first visit, last visit, visits in the last 30 days and monthly spend, which is the play history the franchise could not see at all before. A member who plays at more than one club is one contact carrying every club they play at, which is what makes a head office report possible.

One HubSpot limit shaped the consent design. Marketable status is read only through the API, so the opt out flag from the source drives a HubSpot workflow rather than being written onto the contact directly. Day to day operation is a single check: a healthy night ends with a clean exit for the sync and a clean exit for the rollups, in two dated log files. Ownership transferred in September 2026. The franchise holds the server, the repository and the tokens, and the server we had been running was destroyed after 8 days of green runs on theirs.

One small cloud virtual machine in a Canadian region, running Node 22 and TypeScript directly with no build step. A single cron entry at 02:00 Eastern chains the sync and then the rollups. Run state, cursors and checkpoints sit on disk beside the code, and each phase writes its own dated log with a two week retention.

Locations, owners and teams are configuration files rather than code, so onboarding a club is a credential, a target entry, an owner mapping and a backfill run. None of it needs a release. That choice is also what made the handover simple, because the whole system is a repository, a server image and two tokens.

The sync engine is the only component that talks to both sides, and it talks to them in one direction. It reads each club’s account in turn, maps every record into a HubSpot payload, writes contacts first and then the objects that associate to them, and keeps its cursors and checkpoints on disk so an interrupted night resumes rather than restarts. The rollup pass runs only after a successful sync, then patches the visit and spend properties back onto contacts.

Every object carries its own dedupe key as a property, which is what makes the nightly re-run idempotent. The same reservation seen on two consecutive nights updates one record rather than creating two. Each key is built from the source record’s own identifiers, never from a name or a date.

The contact key is the one exception to that pattern. It is the club’s organization scope combined with the email address, falling back to the member id where there is no email. The scope is what lets two clubs describe the same person without either of them owning the record, while HubSpot still keeps exactly one contact for that person.