HubSpot + Yardi Voyager integration

Occupancy is the number that matters to a senior living operator, and the people responsible for it work in two systems that have never met. Voyager holds the prospect record, the waitlist, the unit and the resident. The marketing team holds the campaigns, the website forms and the tour requests. Between them sits a sales counsellor who retypes an enquiry from an inbox into a guest card, and who cannot tell anyone which campaign filled the suite.

The cost is not abstract. A lead that arrives on a Friday evening waits until Monday because nothing routes it. A family that toured in March gets a first contact email in June. Nobody can report tour-to-move-in conversion by property without exporting two systems into a spreadsheet, so nobody does it monthly. Meanwhile the marketing database drifts further from the resident record, because the only thing keeping them aligned is somebody’s diligence.

There is a privacy dimension that shapes the build more than the speed does. Voyager holds health, financial and demographic fields that must never reach a marketing platform, and family members who are not the resident. A working design carries an explicit exclusion list and an explicit decision about which relationships cross into the portal at all. That conversation happens in discovery, in writing, and it is the reason these programmes start with a data protection review rather than an endpoint.

Six objects cover the estate. Prospects become deals, their people become contacts, residents become contacts with unit and tenure fields, properties become a custom object, and prospect activities and move events become timeline events on the contact.

Identity is the whole design. Contacts upsert on the Yardi contact id and deals on the Yardi prospect id, both held in custom HubSpot properties, and HubSpot’s batch upsert matches on exactly that kind of custom unique identifier, a hundred records at a time. Email is explicitly not an identity here.

Direction follows what the interface will actually accept. Prospects, contacts and residents flow in. Web enquiries flow out as new prospects, contact edits flow out as a read, merge and write so nothing unrelated is blanked, and marketing emails and form submissions flow out as activities. Prospect status does not flow out at all, because no operation exists to write it.

The shape is a scheduled pipeline with a lakehouse in the middle. Raw XML responses land untouched in a bronze layer, cleaned rows in a silver layer, and sync state in a gold layer holding watermarks, routing and the ledgers. The inbound chain runs its steps in order, each gated on the previous one succeeding, while the long activity history pull runs on its own schedule because it takes hours.

Outbound is staged rather than immediate. Changes are collected, queued, transformed to XML, passed through the safety gates, written, then read back to confirm, with every attempt and its outcome recorded in a ledger. That ledger is what makes replay safe: an activity already written is never written twice, however often a run repeats.

The gates matter as much as the pipeline. A master write switch turns every write into a logged dry run. An environment lock asserts that the production job is pointed at production credentials. A portal check refuses any HubSpot write unless the connected portal is the expected one. A blackout guard exits cleanly inside the platform’s maintenance window, and the next run catches up because watermarks and ledgers make that safe.

There is no native route to weigh, so the real choice is between a narrow feed and a programme. A narrow feed is a legitimate first step: enquiries from the website into Voyager, nothing coming back, a few weeks of work. It gives the sales counsellors a faster lead and gives the operator a taste of what joined data looks like.

The programme is what occupancy reporting actually needs, and it is a different order of work: history as well as current state, residents as well as prospects, activities in both directions, and an identity ledger that survives the day someone reopens a contact under a new id. Comparing the two on hours misses the point, because they deliver different things.

1. Scope. We agree which properties are in scope, which fields are excluded on privacy grounds and which relationships cross into the portal, before any credential is issued.
2. Architect. Identity keys first, then the layers, the ledgers and the gates, with every interface behaviour proven by a write and a read back.
3. Build. The inbound chain and the outbound pipeline against the test environment, with the production notebook differing only in its configuration.
4. Validate. A full rehearsal with counts reconciled per object and a dry run that computes everything and writes nothing.
5. Operate. Watch the chain, re-run failed steps in order, and review the conflict table where values the platform sent did not fit.