HubSpot + Zendesk integration

Zendesk is where a customer’s frustrations are written down. Every ticket carries the requester, the organization, the agent’s replies and, once it is solved, a satisfaction rating. None of that reaches the account manager in HubSpot, who is about to ask the same customer for a larger contract and usually hears about the bad month from the customer, on the renewal call.

Support leaders feel the gap from the other side. They cannot tell which organizations sit in an open deal or a renewal, so a customer worth a large expansion waits in the same queue as a free trial. Marketing sends a product announcement to someone whose ticket has been open for a week, and the reply lands in support rather than in sales.

Most of this is solved without a build, which is why this page starts with the apps. HubSpot publishes one that syncs Zendesk users, organizations and tickets as records, and Zendesk publishes one that writes ticket events onto the contact timeline. The engineering questions start at the edges: history older than Zendesk’s archive window, satisfaction and service level detail, and anything HubSpot needs to write back into a ticket. Those edges are where this page spends its time.

Three objects carry the relationship. Zendesk users become HubSpot contacts, organizations become companies, and tickets become HubSpot tickets in a support pipeline, associated to both. HubSpot’s app maps users and organizations both ways and tickets one way, and that direction is right: Zendesk owns the ticket, and HubSpot owns the pursuit.

Keys matter more than they look. Email is the natural match for a user, but an end user can change it, so the Zendesk user id travels in a custom property as the tie breaker. Organizations key on their Zendesk id and never on the name, because agents rename organizations to fix a typo and a name match then creates a second company.

Satisfaction ratings belong on the ticket they rate. Zendesk’s own app already shows them on the contact timeline for solved tickets. When a rating has to drive a HubSpot workflow or a company health score, it needs to be a property on the HubSpot ticket, and that is a build.

HubSpot’s app runs on HubSpot data sync. After the first sync, HubSpot’s documentation says records follow within 10 minutes of a change, and a conflict rule names the app that wins when both sides edit the same field. Zendesk’s own app works through three triggers and a webhook it creates in Zendesk, which post ticket events to HubSpot as they fire.

When a build is needed, it is a polling watermark sync on Zendesk’s cursor-based incremental ticket export. The service stores the cursor rather than a clock, asks for everything that changed after it, and upserts HubSpot tickets in batches keyed on the Zendesk ticket id. Users and organizations follow from their own incremental exports, and a separate pass writes the associations. A trigger connected to a webhook can post a ticket id the moment it changes, which only tells the service to read sooner. State lives in the service, so a replay is a cursor rewind and a restart resumes where it stopped.

Here the question is which records have to exist in HubSpot. If sellers only need to see what a contact has raised, Zendesk’s own app puts ticket events on the timeline and asks nothing of HubSpot’s data model. If service data has to be reportable, filtered and used in workflows, HubSpot’s app is the better start, because it creates real ticket records and syncs organizations to companies.

A custom API integration becomes worth its hours at three points: history beyond the archive, service detail the mappings cannot carry, and writes back into Zendesk. We steer away from an iPaaS here, because ticket volume turns into a per-task bill for work HubSpot’s app already does.

1. Scope. We read the Zendesk plan, the sandbox allowance, how much history sits in the archive, and which service fields must drive HubSpot reports or workflows.
2. Architect. We choose the app or apps, set the conflict rule, the ticket pipeline and its statuses, and decide whether a backfill or a build sits beside them.
3. Build. Setup happens in a Zendesk sandbox and a HubSpot sandbox first, with custom mappings where Data Hub allows and any backfill keyed on the Zendesk ticket id.
4. Validate. We reconcile ticket, user and organization counts against Zendesk and review duplicates from the first week’s sync.
5. Operate. We watch the sync’s error list, keep the triggers documented, and re-check the mapping when either vendor changes a default.