Hubspot Connector and Service Key API Credential Triggers Missing

Feature Requests
1

The idea is:

Add more Hubspot connector triggers. It's possible but n8n needs to add these on backend with an OAuth connection. I am looking to move from Relay to n8n. I set up my OAuth connection to Hubspot in Relay and it was able to set the first trigger step in any workflow step as a Hubspot form submission trigger. There were a VAST number of triggers possible with just that OAuth connection in Relay. It did not need the Developer API key. I had one workflow that needed the Service Key API instead in order to access workflow scope. I see the basic Hubspot to n8n connection has little to no triggers, yet it has access to the exact same connectivity.

Feature Request: Can all of the triggers available in Relay be added as Hubspot triggers in n8n since it’s clearly been made possible in Relay? (screenshots of triggers available)

My use case:

I have 30+ workflows to rebuild that trigger off of events, or criteria being met within Hubspot.

Example triggers I use for workflows:

  • Deal object = closed/won TRUE
  • Contact object submits specific form
  • Note object body contains “consultant update”, etc
  • Deal object properties like: active/inactive, project complete y/n, consultant assigned
  • Deal object pipeline stage enters ‘conversing’

I think it would be beneficial to add this because:

This would add a vast number of Hubspot triggers to user capabilities. n8n is extremely limited and I believe this is an easy fix to update n8n backend with Hubspot's OAuth capabilities and expand your available triggers in n8n users UI.

Any resources to support this?

Screenshots of comparable trigger capabilities attached. I can also provide a screenshare of OAuth set up within Relay for reference to copy in n8n.

Are you willing to work on this?

I am MORE than happy to help with this in whatever way I can. Relay is not shutting down until end of August so I can even show you how it functions there to replicate here in n8n.
2

This is a common gap. The HubSpot node in n8n only exposes a handful of trigger events versus the full workflow-based triggers you get with Relay’s OAuth scope. Until n8n adds more native triggers, a practical workaround is to use HubSpot’s own Workflows feature: build a HubSpot workflow with your condition (deal stage change, form submission, note content, etc), then add a Webhook action that calls an n8n Webhook node. This gets you the same granularity you had in Relay without waiting on core changes, since HubSpot’s workflow engine already supports all the property-based conditions you listed. Happy to help sketch out the webhook payload structure if you go this route.

1 Like
3

Thanks for sharing! Hopefully more native Hubspot triggers get added. :crossed_fingers: Especially with the Relay users all jumping to new tools who used those Hubspot triggers.

Unfortunately, Hubspot recently gated webhook actions in workflows to only those with Professional or Enterprise subscriptions of their new Data Hub offering. I am “grandfathered” in since it was previously available under Sales Pro but if I make a change to my Sales Pro subscription, it will likely get taken away. I can use webhooks now but I really don’t want to build the workflow this way since it could be taken away. I’d prefer to use the Hubspot n8n node or I guess set up the Hubspot Developer API key if that makes it a longer term more stable solution…

1 Like
4

The stable long-term path here is a HubSpot Private App, not the Developer API/public app flow you tried. Private Apps generate a single access token scoped to your account (no client ID or app ID needed), and that token stays valid independent of your Sales Hub tier or any Data Hub webhook gating. Since n8n’s HubSpot node still lacks property-based triggers, pair a Schedule Trigger with an HTTP Request node calling the CRM Search API (POST /crm/v3/objects/deals/search) using filterGroups for things like dealstage or a custom “consultant_update” property, then dedupe against the last run’s hs_lastmodifieddate. This gives you all five conditions you listed (deal stage, closed/won, property changes) without depending on webhook actions that could be revoked. Test the Search API call in Postman first with one filter to confirm the response shape before wiring it into n8n.

5

One migration-safe pattern I would use here is to separate this into two tracks:

  1. Vote for native HubSpot triggers, because Relay clearly proves the demand and it would make migrations much cleaner.

  2. For workflows you need to rebuild before Relay shuts down, avoid relying on HubSpot workflow webhooks if your tier might lose them. Use a HubSpot Private App token plus n8n polling instead.

For each Relay trigger type, map it to either:

  • CRM Search API polling for deal/contact/company property conditions
  • Forms submissions API polling for specific form submissions
  • Engagements/notes search or association lookups for note-body conditions

Then store a small cursor per workflow, usually hs_lastmodifieddate, submittedAt, or the last processed object id, in a Data Table/static data/Sheet. Each scheduled run searches only for records newer than the cursor, branches on the exact condition, then updates the cursor after the downstream action succeeds.

That gives you something stable under your own Private App token, without needing a public marketplace app or Data Hub webhook actions. It is not as elegant as native triggers, but for a 30+ workflow migration it is much safer than building everything around a webhook feature that might disappear with a HubSpot subscription change.