CRM Event

trigger.hubspot_event
TriggerCRM & salesconnection requiredruns in-engine

Registers HubSpot webhook subscriptions on publish; one run per event in the delivered batch.

Start a run when a HubSpot contact, company, deal or ticket changes.

Connection

Required
Yes — the node will not save without one
Auth type
Bearer token
Providers
HubSpot
Secret shape
{"token", "developer_api_key", "client_secret"}
Resolved by
config.connection_id, else node.connection_id
Note
The webhooks API authenticates with the developer API key of the account that owns the app, and signatures are verified with the app's client secret. The private-app token alone cannot do either.

Configuration

5 fields, 2 required. A dotted path is a nested object and name[] an array of objects — the editor renders the same tree.

FieldTypeRequiredDefaultConstraintsExample
app_id
The numeric id of the HubSpot public app that owns the subscriptions (developer account → Apps). A private app cannot be used: its webhooks have no API and Mantle could not clean them up.
stringYes—matches ^\d+$1234567
subscription_types
Which HubSpot events to subscribe to.
arrayYes—≥ 1 characters; array of string["contact.creation"]
property_name
The single property a *.propertyChange subscription watches, e.g. email or dealstage. Required when any propertyChange type is selected; HubSpot subscribes to one property at a time.
stringNo———
max_concurrent_requests
How many deliveries HubSpot may have in flight to Mantle at once.
numberNo106–100—
allow_target_url_takeover
Replace the app's existing webhook target URL. Off by default: the setting is app-level, so replacing it redirects every event the app already delivered somewhere else.
booleanNofalse——

Example configuration

Every value below is the contract’s own example or default — nothing invented.

{
  "allow_target_url_takeover": false,
  "app_id": "1234567",
  "max_concurrent_requests": 10,
  "subscription_types": [
    "contact.creation"
  ]
}

Output

One shape.

event

FieldTypeExample
eventId
HubSpot's own id for this event. HubSpot does not guarantee it is unique, so it is one part of the deduplication key rather than all of it.
string1
subscriptionType
What happened, e.g. contact.creation or deal.propertyChange.
stringcontact.propertyChange
objectType
The object half of subscriptionType.
stringcontact
eventAction
The action half of subscriptionType.
stringpropertyChange
objectId
Id of the contact / company / deal / ticket.
string12345
propertyName
Which property changed. Empty for creation and deletion events.
stringemail
propertyValue
The property's new value. Empty for creation and deletion events.
stringada@example.com
occurredAt
When HubSpot recorded it, epoch milliseconds.
number—
occurredAtIso
The same instant as an ISO-8601 UTC string.
string—
portalId
The HubSpot account the event came from. One app serves every account that installed it, so branch on this when more than one portal is in play.
string62515
appId
The HubSpot app whose subscription delivered this.
string—
subscriptionId
The subscription that matched.
string—
changeSource
How the change was made, e.g. CRM_UI, INTEGRATION, IMPORT.
string—
attemptNumber
HubSpot's redelivery attempt, 0 on the first try.
number—
{
  "appId": "",
  "attemptNumber": 0,
  "changeSource": "",
  "eventAction": "propertyChange",
  "eventId": "1",
  "objectId": "12345",
  "objectType": "contact",
  "occurredAt": 0,
  "occurredAtIso": "",
  "portalId": "62515",
  "propertyName": "email",
  "propertyValue": "ada@example.com",
  "subscriptionId": "",
  "subscriptionType": "contact.propertyChange"
}

Notes

  • HubSpot's webhook target URL is a single app-level setting, so one HubSpot app backs one published workflow. Publishing a second workflow against the same app_id fails rather than stealing the first one's events.
  • One app serves every HubSpot account that installed it: branch on portalId when more than one portal is in play.
  • Filtering is done by HubSpot — subscription_types and property_name decide what is ever sent, so nothing arrives here to be discarded.
  • Runs are deduplicated per portal, subscription, object, occurredAt and eventId together — HubSpot does not guarantee eventId is unique — so a delivery retried up to ten times over twenty-four hours starts one run.
  • Deliveries must be answered within five seconds, which is why the run is accepted and executed asynchronously.

See CRM Event run in a workflow.

In a technical demo we add the HubSpot connection, drop the node on the canvas and let Workflow Health pre-flight it before the first real run.