HubSpot + CourtReserve integration

Racquet clubs grow by noticing things. A member who booked twice a week all spring and has not booked since June is a cancellation waiting to happen. A guest who played four times on someone else’s court is a membership nobody has asked for. Both facts sit in the booking platform, and neither of them reaches the person whose job is to make the call.

Multi location operators feel this hardest. Each club is a separate account with its own key, its own members and its own events, so the head office view is a folder of exports. Nobody can say how many people play at more than one site, which locations share a customer base, or whether a campaign that filled courts in one city did anything in the next. The question gets answered once a quarter by hand, which means it gets answered late.

There is a revenue side too. Leagues, clinics and junior programmes sell out unevenly, and the difference between a full programme and a half empty one is usually a reminder sent to the right forty people. That list is a query over reservations and registrations, and it cannot be built in a system that has no reservation data in it. Clubs ask for this integration when they want lapsed players, programme prospects and membership renewals to behave like ordinary marketing and sales work rather than a manual project.

Six object types cover the club. Members become contacts, memberships, reservations, events and registrations become custom objects, and transactions become deals. Transactions are the only thing that belongs in a pipeline, because they are the only object with money and a close date attached.

Every key is compound: the organization identifier plus the record identifier from that club. Identifiers repeat across clubs, so a bare booking id will collide the moment a second location is added, and the collision looks like a member cancelling a booking they never made. Contacts are the exception. HubSpot allows one contact per email address, so the same person at two clubs is one record, and a multi select property records every club they belong to. That property is merged on each run rather than replaced, or the last club to sync wins and the others disappear.

Everything travels one way. The booking platform stays the system of record for courts and money, and HubSpot is where the conversation happens.

The pattern is polling with a watermark. A nightly job walks each club in turn, reads a short window of members, reservations, events, registrations, memberships and transactions, and writes to HubSpot with batch upserts keyed on the compound identifier, followed by an associations pass that links registrations to both the member and the event. HubSpot API paths are pinned to version 2026-03.

Clubs are processed sequentially rather than in parallel. The documented limit is 60 calls per minute per API key, and running several clubs at once turns a predictable nightly window into a queue of retries. Checkpoint state per club means an interrupted run resumes at the club it stopped on, not at the start.

The write side has to expect conflict. A batch create can fail because the email already exists on a contact created by another club, so the handler requeries the record, merges the club list, and patches rather than discarding the row.

There is no app, so the choice is between a service and an automation platform. Volume and identity decide it. One club, members only, a few hundred records a month: an automation platform will do, and the club will outgrow it the day it wants reservations. Several clubs, six object types and members who appear in more than one of them: you need somewhere to keep a watermark, somewhere to throttle, and a conflict handler that knows a duplicate email is an expected event rather than an error, which is a service you own rather than rent.

The rate limit, the date window, shared members and cancellations are what go wrong on a club sync, and all four are predictable.

1. Scope. We confirm which plan the club is on, because API access starts at the Advance tier, then agree how much history to load and which object types actually get used.
2. Architect. We fix the compound keys, the custom object model and the consent design before any code, since all three are expensive to change after a load.
3. Build. Batch upserts keyed on the compound identifier, a separate associations pass, throttling at the documented limit, and checkpoints per club from the first run.
4. Validate. Everything runs against a sandbox portal behind a fail closed portal allowlist, and the production cutover is a token swap.
5. Operate. Each run writes counts per club, reconciliation compares them against the source, and a backfill script stands ready for the day a club adds a location.