So, I have the application that I have been working on that allows bidirectional sync between the Hubspot Object and the entity in my database.
I use the bidirectional sync using HubSpot’s webhook API inorder to keep the values the same across both system (HubSpot<>My App).
The app that I am working on can be installed by multiple people and all of them can map any property in the app to any custom property in the HubSpot account.
(In the image the fields on the right side are HubSpot custom properties that I created).
Now if I have 100 people installing the app and creating 10 custom fields on their HubSpot account the webhook subscription that I would have to create would easily surpass the limit of 1000 subscriptions, if I have to have the ability to do bidirectional sync between the systems.
Right now I have a webhook endpoint that receives the data from HubSpot if any field changes and I simultaneously update the record in my database too.
Is there any better approach to solving this issue?
Would workflows help, if yes then how? It’s quite overwhelming.
Hey @ArpitAtDock - we hit this exact problem as we were building Sequin.
You’ll run up against the Webhook subscription limitations. And it’s important to remember that Webhooks only support a limited number of objects.
Workflows are another approach, but workflows can be a little hit or miss depending on what action you are trying to capture and transform into a webhook. This makes it really easy to miss the event you need to maintain the sync.
Instead, we went with a polling approach that has worked well. We wrote up this guide:
I hope you find it useful and happy to be a resource here.
Hey @Eric_Goldman , first of all, thank you so much for the reply. I am following a somewhat similar approach to sync Salesforce objects. However, can you shed some light on what issues I might face if I decide to go ahead with the “workflow” approach?
Hey @ArpitAtDock - happy to help!
With Workflows, the issues we’ve run into are two-fold:
1. Workflows not firing: A workflow might not fire on every event, especially on high-frequency events (i.e., an object moving through a set of statuses). It’s rare, but common enough to cause a sync to get broken.
2. Workflows being altered: Workflows can’t be managed programmatically, so key logic is outside your code/implementation. Workflows can be altered / hard to maintain as a result.
Ultimately, workflows felt like a bit of a hack that we wanted to avoid.
@Eric_Goldman do you think a mix of webhook implementation for Hubspot core fields and your implementation for custom fields would work better?
Hi @ArpitAtDock, you’re running into a real constraint: HubSpot caps webhook subscriptions at 1,000 per app, so per-property subscriptions won’t scale (API usage guidelines and limits - HubSpot docs )
The pattern that works at volume is hybrid: keep a small set of webhooks at the object level (create/update/delete) to “wake” your sync, then fetch the actual deltas from HubSpot with the CRM Search API filtered by hs_lastmodifieddate (and whatever properties you mapped). That avoids a subscription per custom field and is resilient if admins add new properties later (Search the CRM - HubSpot docs )
On each webhook hit, call /crm/v3/objects/{object}/search with a GTE timestamp from your last checkpoint, page through results, and upsert to your DB. Also handle backfills or missed events with a scheduled incremental poll. Are these installs using a private app or a public app? That influences how you store checkpoints per portal.
Where native connectors stop short, Stacksync fills the gap with real-time, bidirectional sync so your workflows and reports stay trustworthy.
