HubSpot + Zoho CRM integration

Zoho CRM is one product in a suite that also covers invoicing, accounting, inventory and recruiting, and HubSpot publishes apps for several of those as well as for the CRM. So a HubSpot project that starts with Zoho CRM can touch more than one Zoho product. The first question is about direction: is Zoho staying as the sales system while marketing works in HubSpot, or is the business leaving Zoho altogether?

The two answers need different tools, and HubSpot documents both. The Zoho CRM app is an ongoing data sync, one way or both ways, that keeps records in step for as long as it runs. Leaving Zoho is a job for HubSpot Smart Transfer, a one-way transfer that audits the Zoho org, recreates its properties and pipelines in HubSpot, syncs the records through the same data sync, then carries attachments, notes and deal line items in a one-time pass. Picking the wrong one leaves a sync nobody switched off, or a move that never finished; the migration or integration guide sets out how to tell the two apart.

Data residency is the other question for a Canadian or European team. Zoho hosts each org in a single data centre, in the US, Canada, the EU, India, Australia, Japan or China, and the API domain changes with it. HubSpot’s setup asks which domain to connect to, and any custom work has to call that same domain.

HubSpot’s app pairs Zoho modules with HubSpot objects one by one: accounts with companies, contacts and leads with contacts, deals with deals, products with products, and calls, meetings, tasks and notes with their HubSpot activity types. Invoices come into HubSpot one way. Custom modules pair with HubSpot custom objects on Enterprise subscriptions, where associations have to be mapped by hand.

The first match uses email for people, name or domain for companies, and SKU or name for products. After that, data sync holds each pair by record id, so a renamed account stays paired with its company. Deal stages sync only where the Zoho value matches the HubSpot stage label, and only deals in mapped stages sync at all.

Leads need one decision up front. Converting a lead in Zoho turns it into a contact, or links it to an existing contact with the same email, and HubSpot’s app offers both modules against the one HubSpot contact matched on email. We decide in discovery whether HubSpot receives leads, contacts or both, and what a conversion should look like on the HubSpot side, before the first sync runs.

With the app, HubSpot runs everything. When a module sync is switched on, data sync indexes the records on both sides, pairs the matches and then works incrementally, and HubSpot’s documentation says a change syncs within ten minutes once the initial sync is complete. The app connects to Zoho through OAuth against the domain you pick, and its calls count against the org’s daily API credits like any other integration’s.

When custom work joins it, the shape is a webhook queue with a sweep. A service holds a Zoho OAuth client, whose access tokens last an hour, and enables notification channels for create, update and delete events on the modules in scope. Each event lands on a queue; a consumer reads the full record and upserts into HubSpot on the Zoho record id, with associations in a second pass. A scheduled read with the If-Modified-Since header catches whatever a channel missed, and deletions come from the deleted records endpoint, which lists recycle bin entries for 60 days.

For Zoho, the route turns on three things. The goal comes first: coexistence is the app, while a move is Smart Transfer followed by switching the sync off. Then the pipeline design: one Zoho pipeline maps cleanly, several need a plan. Last, the HubSpot subscription, since custom field mappings need a paid Data Hub subscription and custom modules need Enterprise.

When the app fits, it is the cheapest correct answer, and we configure it rather than build around it. Custom work joins it for pipelines or keys the app cannot express. A per-task automation platform in the middle only duplicates what the app already does, and it spends the org’s credits to do it.

1. Scope. We confirm whether Zoho is staying or going, list the modules and pipelines in scope, and note the org’s data centre and edition.
2. Architect. One direction per module, the conflict winner, the lead and contact decision, and the pipeline and stage map, written down by label.
3. Build. The app is configured with a filtered first sync, the Modified By field checked on every module, and owners provisioned as users in both systems.
4. Validate. We compare counts per module, convert one lead end to end, and change a deal stage on each side.
5. Operate. We review failing and excluded records every week, and watch the credits remaining header whenever custom work shares the allowance.