Quick answer: Cvent-HubSpot attendee numbers usually drift from how the integration matches contacts and calls HubSpot's attendance states - not from either platform reporting bad data. Main culprits: matching by email instead of a stable ID, attendees picked up already checked-in with no "register" call ever made, and stale syncs overwriting correct data. Fix the sync engine, don't just re-run it.
When Your Event Numbers Don't Add Up
Cvent is one of the most widely used event management platforms for registration, check-in, and attendee tracking, and HubSpot is the CRM many of the same teams use to manage the contacts those events generate. When the two are connected, event data is supposed to flow into HubSpot automatically - but the numbers on each side don't always agree.
A marketer opens a HubSpot Marketing Event dashboard the morning after a webinar and sees 48 registrants. Cvent says 30. Nobody on the team changed anything - the sync just ran, like it does every night.
This isn't a rare glitch. It's one of the most frequently reported issues wherever Cvent and HubSpot are connected, whether through the native connector or a custom-built sync. Support tickets on both sides tend to end the same way: Cvent points at HubSpot, HubSpot points at Cvent, and the marketer is left reconciling attendee lists by hand before the next event.
The good news is that the root cause is almost always explainable once you look at how the sync actually moves data between the two platforms - not a mystery, just an integration that wasn't built to handle a few specific edge cases.
How a Cvent-HubSpot Sync Actually Works
The mismatch almost never happens inside Cvent or inside HubSpot - both platforms report their own data correctly. It happens in the middle, in the sync engine responsible for matching, sequencing, and retrying. That's the piece worth understanding in detail:
To understand why the numbers drift, it helps to see what the integration is actually doing behind the scenes. A properly built sync moves data in a strict sequence, and each stage depends on the one before it:
| 1 |
Pull events from Cvent Every event record (title, dates, status) is fetched from Cvent's API. |
| 2 |
Pull attendees from Cvent Every registration, along with its status (registered, attended, cancelled) and survey answers. |
| 3 |
Map attendees to events An internal lookup joins each attendee to their event before anything is written to HubSpot. |
| 4 |
Push events to HubSpot Each Cvent event becomes (or updates) a HubSpot Marketing Event. |
| 5 |
Push attendees as CRM records Each attendee becomes an object in HubSpot CRM, linked back to the event. |
| 6 |
Associate contacts The new record is matched to an existing HubSpot Contact, usually by email. |
| 7 |
Sync participation status HubSpot is told whether each contact is registered, attended, or cancelled for that event. |
| 8 |
Write survey answers Custom registration question responses are attached to the attendee record. |
Every one of the common symptoms - wrong counts, statuses stuck on "registered," duplicate contacts - traces back to one of these steps breaking quietly rather than loudly.
Example: an appointment record after a clean sync
HubSpot custom object · one record per attendee, per event
- •Name - built as first name + last name, event title, and job title joined together, so the record is identifiable without opening it
- •Pipeline stage - set by looking up the Cvent status against the account's own stage IDs, not a hardcoded label, so it still works if stage names change
- •Stable Cvent attendee ID - stored on the record itself and used to find and update this exact appointment on every future run, instead of creating a new one
- •Linked to a Contact - matched on that same stable ID when it's already on file, falling back to an email search (with a tiebreaker for shared inboxes) only for attendees HubSpot hasn't seen before
- •60+ properties synced - registration details, custom questions, and contact fields all copied over in the same pass, not fetched separately later
The Real Reasons Attendee Numbers Go Wrong
1. Contacts matched by email instead of a stable ID
If the integration looks up a HubSpot contact by email address alone, small inconsistencies cause it to miss the existing record and create a new one instead - a typo, a secondary email, or a contact whose primary email changed since the last event. Each duplicate then reports its own partial attendance data, and the totals stop adding up.
A more reliable approach stores the Cvent attendee ID as a dedicated HubSpot property and matches on that going forward, falling back to email search only for genuinely new contacts.
2. Attendees who never get a "register" call
HubSpot's marketing event attendance states aren't a locked sequence enforced by the API - registering, attending, and cancelling are three independent calls, not a required chain. The problem is quieter than that: most integrations only call the endpoint matching an attendee's current Cvent status on a given sync run, not every state they may have technically passed through before the sync ever ran.
If someone registers and checks in before the integration's first sync for that event, the sync sees a fully checked-in attendee and calls only the attend endpoint - HubSpot never receives a separate register call for that person at all. Depending on how registration totals are reported on the account, that attendee can show up in attendance figures while being invisible in registration counts, and the two numbers stop reconciling for a reason that has nothing to do with the check-in itself.
The status-to-state mapping itself is straightforward once it's explicit - the risk is in assuming every attendee passes through each state while the sync is watching, not in the mapping logic:
In practice, most syncs call only the single state that matches an attendee's status at the moment the sync runs - not a full register-then-attend chain. That's fine for anyone the sync catches early. It's the walk-in registrations and same-day check-ins, picked up already-attended on the very first run, who end up with no register call on record at all - which is exactly where the count drifts.
3. No incremental sync
Some integrations re-fetch every event and every attendee from the beginning of time on every run, rather than only what changed since the last sync. Beyond the obvious performance cost, this creates a real risk: if a batch fails partway through a full re-run, the next run can reprocess an inconsistent dataset and temporarily overwrite correct numbers with stale ones.
4. Rate limits causing partial writes
HubSpot's Marketing Events API allows roughly 9 requests per 10 seconds for standard private apps, per HubSpot's own developer documentation. An integration that doesn't respect that limit - or doesn't retry correctly after a 429 response - can end up writing some records in a batch and silently dropping others. The dashboard then reflects a partial sync as if it were complete, because nothing actually threw a visible error.
5. Full-scan lookups instead of targeted search
Some syncs page through every existing record in HubSpot on every run just to build a lookup table, rather than searching only for the records relevant to the current batch. On accounts with a large volume of appointments or contacts, this slows the sync enough that later steps - like status updates - start running against data that's already a few minutes out of date.
6. Failures logged but never surfaced
A sync can fail partway through - one batch of status updates errors out, or a rate limit gets hit one too many times - and the only record of it is a line in a log file nobody is watching. If there's no alert tied to that failure, the first person to notice is a marketer opening a dashboard days later and wondering why the numbers look off. The integration didn't silently corrupt anything; it just failed loudly in a place no one was looking.
This is often the real reason a mismatch takes weeks to get noticed and reported, rather than minutes: the sync has a perfectly good error log, it's just not connected to anything that pages a human.
What a well-built sync gets right: it's worth noting that not everything here is a design flaw waiting to happen. A properly built sync treats a HubSpot "409 Already Exists" response as a success, not an error - per HubSpot's own Marketing Events API documentation, these endpoints are designed to be idempotent, so if the same attendee comes through on two separate sync runs, the association step doesn't create a duplicate, it just confirms the link already exists. That idempotency is what makes it safe to re-run a sync after a partial failure instead of needing to untangle what already went through. It's a small design choice, but it's the difference between a sync you can safely retry and one where every failure needs a manual cleanup pass first.
None of this is unique to Cvent. We see the same pattern of drift wherever event or webinar data feeds a CRM without proper matching and sequencing logic - it's the same root cause behind most CRM-to-CRM and CRM-to-ERP integration failures we've written about before, not something specific to events. It's part of why we treat HubSpot CRM integrations as a data-flow design problem, not a one-time setup task.
DIY or Bring in a Specialist?
How Loncom Approaches Cvent-HubSpot Sync Issues
We treat a mismatched attendee count as a data-flow problem first, not a support-ticket problem. Before touching any configuration, we trace the sync end to end - how events are matched, how contacts are associated, and in what order statuses are written - to find exactly where the two platforms stop agreeing.
"The integrations that break loudly get fixed fast. The ones that break quietly - a failed batch, a missed status update - can sit wrong for weeks before anyone notices, because nothing was built to tell them," Antonio Karneluti, CTO of Loncom Consulting, says.
From there, we rebuild the integration to handle contact matching against a stable ID, make sure every attendee gets a register call even when the sync first catches them already checked-in, and sync incrementally so a failed run doesn't silently corrupt the next one. Where the underlying data already has duplicate contacts or inconsistent Cvent IDs, we clean that up before touching the sync engine - patching an integration on top of dirty data just moves the same problem faster.
We see this most often with the media and events organisations we work with, where a single conference can generate thousands of attendee records across dozens of sessions - the kind of volume where a small matching or sequencing bug in the sync stops being a minor annoyance and starts being a genuine reporting problem.
FAQ
Why does HubSpot show more attendees than actually registered in Cvent?
Usually because contacts are being matched by email and small inconsistencies (a typo, a secondary email, a changed primary address) cause the integration to create a duplicate record instead of updating the existing one. Each duplicate then carries its own partial attendance data.
Why are attendee statuses stuck on "registered" even though people attended?
Usually the reverse problem is more common: an attendee who registered and checked in before the sync ever ran gets picked up already-attended, and no separate "register" call is ever made for them. Whether that shows as "stuck on registered" or "missing from registration counts" depends on how the account reports totals, but the root cause is the same - the sync only calls the state matching the attendee's current status, not every state they passed through.
Is this a Cvent problem or a HubSpot problem?
Almost always neither on its own. Both platforms are doing what they're configured to do - the mismatch lives in how the integration matches records, sequences status updates, and handles retries, not in either system individually.
Does the native Cvent-HubSpot connector fix these issues automatically?
The native connector works for straightforward setups, but users consistently report the same categories of issues on custom fields, dropdown mapping, and attendee counts once event volume grows. A custom-built sync gives you control over matching logic and status sequencing that the native connector doesn't expose.
How long does it take to fix a Cvent-HubSpot sync issue?
A scoped audit of the sync engine typically takes one to two weeks. The fix itself depends on whether the underlying HubSpot data already has duplicate contacts or inconsistent IDs that need cleaning up first.
Why didn't anyone notice the sync was failing sooner?
Most syncs log errors to a file rather than raising an alert. Unless that log is connected to monitoring, a failed batch can sit unnoticed for days or weeks until someone happens to check a dashboard and spots the mismatch themselves.
Can running the sync twice create duplicate attendees in HubSpot?
It shouldn't, if the integration is built correctly. A well-designed sync treats HubSpot's "already exists" response as a success rather than an error, so re-running it after a failure doesn't create duplicate associations - it just confirms the ones that already exist.
Leave a comment