HubSpot + Mortgage Automator integration

A private lender’s pipeline has two halves that rarely meet. Deals arrive from brokers and referral partners, get quoted, and sit in a spreadsheet or a sales inbox. Funded loans live in Mortgage Automator, where servicing, draws, payments and investor allocations actually happen. The people chasing the next deal and the people servicing the last one work from different screens, and neither screen shows the whole relationship.

That split costs a lender in three places. Broker relationships have no scoreboard, so nobody can say which broker sent the most funded volume this quarter without exporting and pivoting. Renewals and maturities stay invisible to the sales side until someone remembers to look. Investors, who are the other half of the business, end up managed out of an inbox because their accounts are not in the customer system.

Bringing the loan book into HubSpot fixes the reporting problem first. A funded loan as a closed deal, associated to its borrower and its broker, turns maturity dates into workflow triggers and broker volume into a report anyone can run. The lenders who ask for this are usually running a mortgage investment corporation or a small fund, with one operations person holding the whole picture in their head. They want the deal record and the loan record to be the same conversation, not a data warehouse.

Eight pairs cover the model, and they split cleanly by who owns the record. People and firms move both ways: borrowers and broker staff become contacts, broker firms become companies, and an investor becomes whichever of the two it is in real life. Loans, investment accounts and investments move one way into HubSpot, because a loan’s terms belong to the servicing system and nothing good happens when a salesperson edits them inside a deal.

Every pair keys on a Mortgage Automator identifier written to its own unique number property in the portal. Borrower id, broker id, broker staff id, investor id, loan id, investment account id and investment id each get a property, and the upsert matches on that property rather than on a name or an email address. Email is the obvious choice and the wrong one, because a broker principal who also invests has one email and two roles, and a borrowing couple usually shares a single address between them.

The API carries no webhooks, so the sync is pull based and the runtime is a scheduled reader with durable state. Loans ride the created and updated change feeds: the service lists a feed, writes the HubSpot side, and only then acknowledges the batch. Acknowledging before the write commits loses the item, because the feed keeps nothing it believes you already have. Every other entity is a paginated scan, diffed against a stored content hash so an unchanged record costs a comparison rather than a write.

State sits beside the sync rather than inside it: a cursor per feed, a watermark per scan, and a link table holding the identifier pair and the hash. A replay re-reads from the watermark and lands on exactly the same records, because each write is an idempotent batch upsert keyed on the source id, followed by a separate associations pass. Writing objects and their associations in one call is how a half-finished run leaves orphaned records behind.

The choice here is not between vendors, because there is no listed app to choose. Our own HubSpot and Mortgage Automator sync app is in development for the HubSpot Marketplace and is not listed yet, so it is not a route anyone can take today. What is available now is a keyed service we scope and build, or a per-task automation platform. A per-task tool moves a single trigger well and proves an idea in an afternoon. It struggles with the loan graph, where a loan needs its borrower, its broker and its investment accounts associated in a specific order, and each association is another billable task.

The question that decides a build’s size is write-back. Read-only into HubSpot is markedly cheaper and lands faster. Two-way on people and firms is where conflict rules, echo suppression and most of the upper effort band live.

Three of these failures belong to the Mortgage Automator API and one to HubSpot.

1. Scope. We read the loan book’s shape first: which pairs matter, whether investors are people or entities, and whether write-back is in or out.
2. Architect. We agree the property group, the identifier property for each pair, and the map from loan status to deal stage before any code is written.
3. Build. The change feed reader, the scan differ and the associations pass, with the field mapping held as data so a later change is a configuration edit rather than a release.
4. Validate. Everything runs against a HubSpot sandbox first, behind a fail-closed portal allowlist so a misconfigured token cannot write to the wrong portal. Production cutover is a token swap.
5. Operate. A reconciliation endpoint, a replay endpoint that re-runs from a chosen watermark, and a parked-records queue an operations lead can clear without us.