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.
| Field | Type | Required | Default | Constraints | Example |
|---|---|---|---|---|---|
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. | string | Yes | — | matches ^\d+$ | 1234567 |
subscription_types Which HubSpot events to subscribe to. | array | Yes | — | ≥ 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. | string | No | — | — | — |
max_concurrent_requests How many deliveries HubSpot may have in flight to Mantle at once. | number | No | 10 | 6–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. | boolean | No | false | — | — |
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
| Field | Type | Example |
|---|---|---|
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. | string | 1 |
subscriptionType What happened, e.g. contact.creation or deal.propertyChange. | string | contact.propertyChange |
objectType The object half of subscriptionType. | string | contact |
eventAction The action half of subscriptionType. | string | propertyChange |
objectId Id of the contact / company / deal / ticket. | string | 12345 |
propertyName Which property changed. Empty for creation and deletion events. | string | |
propertyValue The property's new value. Empty for creation and deletion events. | string | ada@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. | string | 62515 |
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.