HubSpot + Naviga integration

A publisher’s service desk spends its day answering three questions: what does this person subscribe to, when does it expire, and where is the order they placed last week. Naviga answers all three, and almost nobody outside circulation has a login. So the answers arrive by phone call, by spreadsheet, or not at all, and the rep who took the call retypes them into a note.

The cost shows up at renewal. Retention campaigns need an expiry date that a workflow can read, and an expiry date that lives only in the circulation system cannot enrol anyone in anything. Marketing ends up building lists from a monthly export that is stale the day it lands, and the accounts nobody chased show up later as churn that looked avoidable in hindsight.

Order taking has the same shape from the other side. A rep who sells a book or a subscription over the phone has to open a second system, key the order again, and hope the account and the campaign code are right. When the order is wrong, the correction happens in a third place. Publishers ask for this integration when they want the renewal date where the workflows run, the order status where the service team already works, and one path for placing an order that both systems agree on.

Six object types carry almost all of the value. Customer accounts become companies, customer contacts become contacts, subscriptions and orders become custom objects, publications become products, and a HubSpot native order request travels the other way.

Every one of them keys on the Naviga identifier, stored in a custom HubSpot property, because the obvious keys do not hold up. Account names are edited by service staff as households change, and email is shared across family members, business accounts and school addresses, so a sync keyed on email merges people who are not the same person. Circulation data has duplicate emails by design, and any design that ignores that will produce a contact list nobody trusts.

Direction is deliberate and mostly one way. Naviga stays the system of record for subscriptions, pricing and confirmed orders. HubSpot owns the conversation, the pipeline and the intent to order. The single object that flows back is the order request, and even that one only becomes a real order after Naviga has validated it.

The pattern is polling with a watermark. A scheduled job reads each flow in turn, normalizes what it finds, and writes to HubSpot with a batch upsert keyed on the source identifier, followed by a separate associations pass. HubSpot API paths are pinned to version 2026-03 so a platform change never arrives as a surprise.

Run state lives in the middleware, not in memory. Each flow holds a lock so two runs cannot overlap, a checkpoint so an interrupted run resumes where it stopped, and a run record that says what it read, what it wrote and what it skipped. Outbound calls to both systems pass through one admission control layer, because rate limits are counted per app and several flows competing for the same budget is how a nightly window turns into a morning incident.

Order processing runs on a trigger rather than a schedule. A stage change in HubSpot raises an event, the service deduplicates it, validates against Naviga, and only then creates the order. Every outcome is persisted so an operator can replay a single request without touching the rest.

There is no app to install, so the real choice is between a service you own and an automation platform you rent. The deciding factor is state. Naviga offers no event feed we could verify, and change detection differs by object, so something has to remember what it already read and what it still owes. An automation platform has nowhere to keep that. It can run the order request trigger competently, and it will struggle with a nightly customer reload it bills by the record. A middleware service costs more up front and is the only route that gives you replay, reconciliation and a place to put the validation rules the order path needs.

Change detection, discovery endpoints, duplicate emails and overlapping runs cause nearly all of the trouble on a Naviga build.

1. Scope. We map the properties the publisher actually needs, then test every endpoint that would supply them against their environment, and publish a gap list that marks each field available, available with work, or not there at all.
2. Architect. We fix the object model, the keys and the direction of travel first, then the runtime shape: what polls, what triggers, where checkpoints live.
3. Build. Idempotent batch upserts keyed on the source identifier, a separate associations pass, admission control on every outbound call, and run records from the first commit rather than the last week.
4. Validate. Everything runs against a sandbox portal first, behind a fail closed portal allowlist, and the production cutover is a token swap against code that has already been proven.
5. Operate. Reconciliation counts each run, replay endpoints let an operator recover a single order, and we review the gap list again when the publisher’s platform changes.